ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Société Nationale des Chemins de fer Francais S N C F

String: sncf

Originally Posted: 13 June 2012

Application ID: 1-1871-30331


Applicant Information


1. Full legal name

Société Nationale des Chemins de fer Francais S N C F

2. Address of the principal place of business

34, rue du Commandant René Mouchotte
Cedex 14
Paris 75699
FR

3. Phone number

+33 1 53 25 60 00

4. Fax number

+33 1 53 25 89 17

5. If applicable, website or URL

http:⁄⁄www.sncf.com

Primary Contact


6(a). Name

Mr. Louis BLERIOT

6(b). Title

Chief information security officer - Communication Department

6(c). Address


6(d). Phone Number

+33 1 53 25 60 00

6(e). Fax Number

+33 1 53 25 89 17

6(f). Email Address

contact-j-nomsdedomaine@sncf.Fr

Secondary Contact


7(a). Name

Ms. Valérie Beunèche

7(b). Title

Intellectual Property Legal Counsel Manager

7(c). Address


7(d). Phone Number

+33 1 53 25 82 72

7(e). Fax Number

+33 1 53 25 87 10

7(f). Email Address

valerie.beuneche@sncf.fr

Proof of Legal Establishment


8(a). Legal form of the Applicant

Etablissement Public Industriel et Commercial - Public institution which is both into industrial and commercial activities.

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

France

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

Attachments are not displayed on this form.

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

Barbara DalibardSNCF Voyages division
Bénédicte TilloySNCF Greater Paris area (SNCF Proximités division)
Bernard EmsellemEcomobility
Claude SolardSNCF Regions (SNCF Proximités division)
David AzémaStrategy and Finance
François NoguéHuman Resources
Guillaume PepyChairman
Jacques DamasRailway Service Safety and Quality
Jean-Pierre FarandouSNCF Proximités division
Patrick RopertCommunications
Pierre IzardSNCF Infra division
Sophie BoissardGares & Connexions division
Sylvie CharlesFret SNCF (SNCF Geodis division)

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

Government of FranceNot Applicable

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.

sncf

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.

Attachments are not displayed on this form.

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.

The .sncf string and A-Label were developed in line with and checked against the eligibility, stability and policy criteria as stated in the ICANN Applicant Guidebook - version 2012-01-11. The results of those checks are as follows:

	- The string has less than 63 characters;

	- The string in ASCII is composed of three or more visually distinct characters;

	- The ASCII label consists entirely of letters;

	- The string is not a reserved name as shown in section 2.2.1.2.1 - Reserved Names of the ICANN Applicant Guidebook - version 2012-01-11; and

	- .sncf is not identical or similar to any of the top 10 invalid TLD’s responsible for the majority of DNS pollution, as referenced in the Security and Stability Advisory Committee (SSAC)’s report on this topic at http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac045.pdf. It is likely that the .sncf has not already been queried with meaningful frequency at the root. Therefore, it is unlikely that .sncf will inherit significant invalid query traffic.


Due to the positive results of these checks, SNCF does not believe that the .sncf gTLD will be subject to any operational or rendering problems.

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.

The mission and purpose of the new restricted .sncf gTLD is to benefit internet users by ensuring increased trust, convenience and utility.

The .sncf gTLD will create a new generation gTLD serving the interests of end users by providing an authoritative Internet space where information, services and resources of the brand and, potentially, its affiliates and partners that are associated with the brand will be closely controlled by Societe Nationale des Chemins de fer Francais (SNCF). The majority of the anticipated domain name registrations in the .sncf gTLD will be used in the promotion and communication of the SNCF brand and its rail services. A subset of domain names has the potential to be created and used for communication and marketing purposes, with internet users assured of brand authenticity.

SNCF, also known as the French National Railway Corporation, was established in 1938. SNCF is France’s national state-owned railway company that offers an extended range of services to ensure door to door mobility for clients including passengers, transport, logistics operators and regional and local Transport Organizing Authorities. SNCF has 5 main areas of expertise:
1. SNCF Infra (rail and related infrastructure): In 2010, SNCF Infra had 15,000 trains running daily across 36 countries.
2. SNCF Proximites (local, urban and regional passenger services): SNCF Proximites transported an average of 10 million passengers per day in 2010.
3. SNCF Voyages (operating long-distance and high-speed passenger rail services): SNCF Voyages and its subsidiaries carried 132 million passengers in 2010 and the www.voyages-sncf.com website is the leading online travel agency in France, with over 10 million visitors per month and an additional 2 million visitors per month accessing Voyages-sncf.com via mobile phones.
4. SNCF Geodis (providing freight and logistic services): SNCF Geodis was operating in 120 countries across 5 continents and was ranked No 1 in France and No 2 in Europe leading European operator in freight transport and logistics and the 7th leading operator worldwide in 2010.
5. Gares & Connexions: Gares & Connexions, which handles train-station management and development, has about 2 billion travellers transit through their stations each year and was operating about 3,000 passenger stations in France in 2010.

SNCF is present in 120 countries, employs over 240,000 people and has generated revenue of €30.5 billion in 2010, €33 billion in 2011. As a world leader in the area of mobility and logistics, continuous innovation and consumer trust are paramount considerations in SNCF’s activities.

Business activities are increasingly conducted over the internet, allowing for greater levels of interaction between businesses and customers. As a result, both businesses and end users benefit from ease of interaction and a wider range of choices with lower transaction costs. However, the development in this arena in the current domain name system has exposed both businesses and consumers to increased criminal activities over the internet, including data breach, hacking and phishing. These sophisticated criminal activities cause reputational damage to businesses as internet users lose consumer confidence and trust with the businesses targeted by such criminal activities. The .sncf gTLD will facilitate greater trust and assurance from internet users connecting with SNCF online, whilst still allowing convenient and efficient interaction.

SNCF’s mission and purpose of the proposed new gTLD share ICANN’s initiatives to promote public interest. SNCF is committed to contribute towards achieving such initiatives in line with ICANN’s Affirmation of Commitments, which includes:
- consumer trust: the .sncf gTLD registry will be operated in a centralised manner with a restrictive registration policy. Registration of domain names will only be available to SNCF, at this stage, which will provide added consumer trust that .sncf domain names are trustworthy. As the .sncf domain names are subject to registration standards, policies and procedures under SNCF’s control, this eliminates the possibility of malicious conduct within the .sncf domain space;
- competition: the proposed new gTLD is not intended to instigate competition and consumer choice at the level of registration of domain names among prospective registrants. Instead it is anticipated to contribute to ICANN’s initiatives to promote public interest through its operation focused on promoting consumer trust. Increased trust in the .sncf gTLD will drive existing and new top level domain (TLD) registry operators to make improvements in mechanisms to improve consumer trust of their TLDs; and
- consumer choice: the proposed new gTLD will enable user-driven improvements and innovations assisting SNCF’s marketing efforts through its ability to create new second and third level domain names on demand. These names will provide the consumers with more choices for interacting with SNCF. As SNCF has effective control over the registration and use of domain names under the .sncf domain space, this will also contribute towards general service innovations on the internet.

Given the restricted nature of the .sncf gTLD, the projected number of registration is likely to be limited. It is anticipated that up to 1000 domain names will be registered in the first year. However, over the next few years, the number of registrations is likely to increase to about 2000 domain names as SNCF create relevant domain names for use including product and services related to its rail services.

SNCF will utilise Internationalized Domain Names (IDNs) at the second level, including French, Asiatic (including Japanese, Chinese and Korean), Arabic and Cyrillic languages. The use of IDNs will allow internet users to engage with .sncf in their native language, creating a more positive user experience and encouraging diversity. As the use of the .sncf gTLD evolves, it is anticipated that the use of IDNs, including additional languages, will increase within the .sncf domain space.

SNCF is a well-recognised global brand with its “SNCF” trademark registered in 11 countries and territories including the EU, the US and China for categories such as Vehicles (Class 12); Transportation and storage (Class 39); Hotels and Restaurants (Class 43). Its “SNCF Assistance”, “SNCF Conseil”, “SNCF Consulting”, “SNCF La Radio”, “Le Train SNCF”, “Le Train by SNCF”, “Le Train from SNCF”, “Fret SNCF”, “SNCFI”, “SNCF International” trademarks are also registered in many countries and most of the time in the same categories as mentioned.

SNCF has 67 existing domain names with an exact match to the applied-for .sncf string and its “SNCF” trademark in domain spaces including but not limited to sncf.com, sncf.travel, sncf.fr and sncf.jp. The company also has an existing domain name in Russian IDN in снцф.рф.

Recently, SNCF was successful in securing sunrise application for 16 domain spaces such as sncf.asia, sncf.xxx and an SNCF domain name in Chinese IDN in 法国国营铁路公司.asia based on existing trademark registration.

SNCF believes that the .sncf gTLD is unlikely to cause confusion with either a generic term or any existing TLDs. SNCF trademarks are a leading global brand with significant reputation for its rail services in Europe and operates with a strong reputation in countries all around the world. SNCF has used the term “SNCF” as a renowned brand in conjunction with its mobility and logistics businesses for over 70 years.

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

18(b)i. What is the goal of your proposed gTLD in terms of areas of specialty, service levels or reputation?

The key goals of the proposed new .sncf gTLD are in line with ICANN’s Affirmation of Commitments: to promote consumer trust, competition and consumer choice. SNCF also seeks to foster its online reputation and provide an authoritative internet space through which SNCF is able to communicate with its customers and passengers directly and effectively. The ability to create domain names on demand related to specific marketing, specialty service and product development supports these goals. Strengthened security measures, service levels and more effective functionality will provide a trusted and positive user experience.

18(b)ii. What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?

It is anticipated that the proposed .sncf gTLD will make positive contributions to the wider internet community by providing:

Differentiation (Increased trust):
The .sncf gTLD will simplify how internet users interact with SNCF by providing a distinctive domain space for its uses including passengers engaging with SNCF through their mobile devices or for its online ticket booking services. Internet users and SNCF train passengers will be able to directly navigate to the .sncf gTLD site, saving time and resources searching for an official site or the relevant information they seek. Further, SNCF plans to develop specific sites to provide direct and target specific communication to their different consumer groups. The current domain name system has shown that it is vulnerable to malicious abuses due to registration of domain names which seek to exploit consumer confusion. SNCF can address some of these vulnerabilities by maintaining complete control over the domain names registered under the .sncf domain space and limiting such registrations to its exclusive use at the initial stage. Together with consumer trust and confidence, internet users will be able to rely on the authoritativeness of the domain names under the .sncf domain space, which will differentiate interaction between internet users and SNCF online.

Competition:
The differentiation of .sncf gTLD as a trusted site for SNCF will drive existing and new TLD registry operators to make improvements in mechanisms to improve consumer trust of their TLDs. Internets users will be encouraged to interact with domain names under .sncf domain space. As a result, .sncf will have a flow on effect to enable increased competition. Therefore, the benefits of the proposed .sncf will be distributed not only to its direct customers, but to the internet community at large forcing improved services and competitive pricing in the market place.

Innovation:
With the expansion of the internet community to all corners of the world, the existing TLD structure presents limitations, not only in the availability of domain names for registrants, but also to businesses and organisations establishing a coherent global online brand presence to meet their evolving business needs. It is often difficult to register a domain name in existing domain space due to unavailability of the desired name. This problem is amplified for organisations such as SNCF who work across many different jurisdictions and geographical markets. Even when the desired domain name is available, it may come with a high price tag associated with a purchase of such desired name from a third party. SNCF has the ability to create second or third level domain names including the use of IDNs on demand which are relevant to its customer base, services and products. For example, SNCF Voyages will be able to innovatively utilise the .sncf gTLD to assist its customer to book tickets online in a more efficient and convenient way. With complete control over the .sncf domain space, SNCF seeks to strengthen its brand reputation as the world leader in mobility and logistics services. SNCF will be able to combine its use of the domain space with innovative user focused marketing and services to address the currently unmet needs in the existing domain name system providing greater consumer choice and better customer communication.

18(b)iii. What goals does your proposed gTLD have in terms of user experience?

The proposed .sncf gTLD will provide a positive user experience, which meets the changing and growing needs of the global internet community. SNCF will maintain control in the registration and use of domain names and will ensure that the new gTLD will only be used for purposes authorised by SNCF. Therefore, the .sncf gTLD will:
- provide an easy and intuitive reference and access point for internet users;
- allow SNCF to communicate directly and efficiently with target specific content to their customers and passengers;
- represent authenticity thus promoting user confidence;
- direct internet users to relevant information in a timely manner by creating domain names on demand to cater to SNCF’s customer groups;
- use IDNs to enable customer to interact directly in their native language;
- allow the use of geographic names to localise its websites to connect with internet users in the relevant regions and to comply with local laws;
- enhance security and minimise security risks by implementing necessary technical and policy measures;
- strengthen brand reputation and user confidence by eliminating user confusion; and
- prevent potential abuses in the registration process reducing overall costs to businesses and users.

SNCF does not intend to use geographic names in the second level initially. However, as the use of .sncf develops, SNCF may wish to use geographic names, at a later stage, to localise its websites in the 120 countries in which it operates. The use of geographic names will be in accordance with registration policy and the proposed measures for protection of geographic names as outlined in response to Question 22 and is intended to:
- connect internet users with relevant information as applicable to the territory; and
- comply with required rules and regulations in the relevant territory.

The .sncf gTLD should address the concerns that the current domain name system is open to potential malicious abuse and user confusion in the registration processes. Although the current system allows an eligible party to lodge a claim through existing Uniform Domain Name Dispute Resolution Policy (UDRP) or other dispute resolution processes, the .sncf will reduce potential abuses in the registration processes and overall costs to internet users. User confidence in the domain name system will be strengthened, which will ultimately contribute towards promoting ICANN’s core values in benefiting the public interest.

18(b)iv. Provide a complete description of the applicantʹs intended registration policies in support of the goals listed above.

The proposed registration policy is attached in response to Question 28.

Only SNCF will be eligible to register domain names in .sncf at this stage. The domain name registration processes will address the requirements mandated by ICANN, including rights abuse prevention measures.

18(b)v. Will your proposed gTLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures.

SNCF is committed to protection of privacy and confidential information in accordance with its objective of increasing consumer trust and providing a safe and legitimate internet space for internet users. Privacy and confidential information will be protected in accordance with all applicable laws and regulations relating to internet security, privacy and user’s confidential information including Receipt No. 1253753 of the CNIL (French National Freedom of Information Commission) and Article 38 of Act No. 78-17 (Freedom of Information Act).

Privacy is of fundamental concern to most of SNCF’s customers as the interaction between SNCF and its customers may involve monetary transactions. As such SNCF has a strong interest in ensuring a high level of privacy protection for its customers. SNCF has also implemented its own privacy policy to demonstrate its commitment to the protection of user privacy and confidential information.

The purpose of SNCF’s websites is to enable SNCF to contact with its internet users. SNCF will only use the data gathered through its website for the purposes of professional communications, to process user requests and to improve the quality of service provided to its customers. However, SNCF ensures that users are aware that SNCF may be obliged, in certain circumstances such as by reason of legal or fiscal procedures, to provide the gathered data to the relevant authorities.

As the .sncf gTLD will only be available to SNCF, initially, the amount of personal data that will be collected for the purposes of operating the gTLD and made publicly available in the WHOIS database will be very limited. SNCF will provide a publicly available and searchable WHOIS look up facility, where information about the domain name status, registrant information including administrative and technical contact details can be found in accordance with Specification 4 of the Registry Agreement. In order to prevent misuse of the WHOIS look up facility, SNCF will utilise measures including a requirement where any person submitting a WHOIS database query is required to read and agree to the terms and conditions in accordance with the registration policy. This will include the terms of use that the WHOIS database is provided for information purposes only and that the user agrees not to use the information for any other purposes such as allowing or enabling the transmission of unsolicited commercial advertising or other communication.

SNCF will deploy Domain Name System Security Extensions (DNSSEC) which is intended to benefit both SNCF and its users interacting with SNCF online. DNSSEC provides additional security by validating information in the transmission, therefore it is intended to benefit those who publish information in the domain name system (DNS) and the users who retrieve information from the new .sncf gTLD. SNCF already implements measures to protect privacy or confidential information of its users against misuse, loss, alteration and unauthorised access. Such measures include:
- use of passwords;
- use of data encryption; and
- use of Secure Socket Layers (SSL).

SNCF will continue to apply all security measures currently implemented and will comply with all other policies and practices required by ICANN in the Registry Agreement and any relevant Consensus Policy for protecting the privacy and confidential information of registrants and users in the new .sncf domain space.

18(b)vi. Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

The proposed new gTLD will be publicised by a media plan to promote recognition of the new gTLD within the internet community to be a trusted site and as a sign of authenticity.

During the initial stage of the operation of the proposed new gTLD, it is anticipated that internet users will be re-directed to current websites. However, over time, it is foreseen that communication to the internet community of the existence of the proposed new gTLD and encouragement to utilise the trusted site will contribute towards minimising malicious abuses and protecting internet users.

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

As a restricted gTLD, registration will only be open to SNCF at this stage and no third parties will be able to register domain names under the .sncf domain space. Therefore, it is not anticipated that third party trademark owners will incur costs in relation to the .sncf gTLD. All the policy requirements for registration will be satisfied. SNCF will utilise the services of the proposed Trademark Clearinghouse to ensure that domain names registered and the use of those domain names, do not infringe any registered third party intellectual property rights.

No unaffiliated third party will be permitted to register domain names at this stage. It is estimated that time and money spent by consumers who have been targeted by malicious abuse in utilising services on the internet will reduce over time as a result of the new, trusted .sncf gTLD.

18(c)i. How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?

The initial use of the proposed new gTLD will be restricted to internal business use and SNCF is intended to be the only registrant under the .sncf gTLD. Therefore conflicts between multiple applications are not anticipated to occur.

18(c)ii. Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).

This gTLD will be used for internal purposes only, at this stage, so pricing incentives are not applicable or relevant.

18(c)iii. Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plan.

This gTLD will be used for internal purposes only, at this stage, so pricing incentives or pricing increases are not applicable or relevant as no additional fees are to be charged.

Community-based Designation


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

No

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

Attachments are not displayed on this form.

Geographic Names


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

No

Protection of Geographic Names


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

§2 The reservation of two-character label string may be released to the extent that Registry Operator reaches agreement with the government and the country-code manager. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country names. 

§5… the reservation of specific country and territory names may be released to the extent that the Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.

SNCF generally respects and abides by the GAC’s Principles regarding New gTLDs, dated March 28, 2007. In particular, SNCF adheres to and⁄or intends to adhere to the recommendations directed towards new registry operators in Sections 2.1, 2.4, 2.7(b) On the other hand, SNCF assumes that several of the recommendations directed towards new registry operators, in general, are less applicable in the case of Single-Registrant operational models such as .sncf than in an completely open Registry model. These include without limitation Sections 2.2, 2.3, 2.7(a) and 2.9.

In order to comply with the requirements of the Registry Agreement, Specification 5, and as with all other domains in the .sncf TLD, all Two-character labels (§2) and Country and Territory Names (§5) will be initially reserved. However, SNCF believes that the use of geographic terms can provide great benefit and simplicity to internet users because these terms are intuitive ways to resolve to SNCF’s content that is specifically relevant and targeted to users in the particular geographic region and in line with local customs, laws and regulations. The use of the geographic terms will be valuable to internet users because they can be reassured that the content that they are viewing is relevant to their local situation thus mitigating the risk of unnecessary user confusion.

SNCF intends to use any Two-character label and⁄or Country or Territory Name domains in SNCF’s discretion, and to participate in or implement a process by which any Government may reasonably object to that use. SNCF envisions a number of possible scenarios for ensuring Government agreement to the use of Country and Territory names. These will be explored in detail with ICANN and the Governmental Advisory Committee to ensure a mutually agreeable solution. Scenarios range from at a minimum; SNCF informing the Chair of the Governmental Advisory Committee (GAC) to ICANN in writing of its proposed use of geographic terms and provide Governments who wish to do so with an opportunity to block the use of their relevant name in the .sncf TLD. Other plausible scenarios would include;

SCENARIO 1 (Letter to GAC)

In advance of any use of geographical names SNCF will send a letter to the chair of the Governmental Advisory Committee (GAC) informing the GAC of its intention to use geographical names in the .sncf TLD. The letter will outline the reasons for using geographical names and provide Governments with the opportunity to contact SNCF within 90 days to reserve their respective geographical name from use in the TLD. Should a Government inform SNCF that it wishes to reserve the use of their respective geographical name, the name will remain reserved for the duration of SNCF’s registry agreement with ICANN. The opportunity to reserve a name will be offered to Governments free of charge.

SCENARIO 2 (Letter informing individual Governments)

In advance of any use of geographical names SNCF will send a letter to the Government concerned and inform it of SNCF’s intention to use geographical names in the .sncf TLD. The letter will outline the reasons for using geographical names and provide the Government with the opportunity to contact SNCF within 90 days to reserve its respective geographical name from use in the TLD. Should the Government inform SNCF that it wishes to reserve the use of its respective geographical name, the name will remain reserved for the duration of SNCF’s registry agreement with ICANN. The opportunity to reserve a name will be offered to the Government free of charge.

SCENARIO 3 (Letter requesting permission from individual Government)

In advance of any use of geographical names SNCF will send a letter to the Government concerned and inform it of SNCF’s intention to use geographical names in the .sncf TLD. The letter will outline the reasons for using geographical names and request the Government’s approval or non-objection to the proposed use of the geographical name. Should the Government not respond to the SNCF within 90 days, SNCF will understand this to mean that the Government does not object to SNCF’s proposed use of the geographical name. However should the Government at a later stage contact SNCF and request that the geographical name no longer be used, SNCF will work in good faith with the Government to try to find a mutually agreeable solution.
Alternatively: However should the Government at a later stage contact SNCF and request that the geographical name no longer be used, SNCF will work in good faith with the Government to try to find a mutually agreeable solution. If such a solution cannot be found SNCF will respect the Government’s wishes and reserve the name from use without cost to the Government concerned.

Generally, it is extremely unlikely that SNCF’s tightly controlled use of any cc.sncf or countryname.sncf domain name could be confusing or detrimental to users, or otherwise offensive to any country. Nor is it likely to be detrimental to the operator of a country code top level domain. To the extent that use of any .sncf domain was ever deemed confusing or offensive, SNCF has a strong desire to resolve the situation quickly and respectfully to any affected Government’s sovereign interests. SNCF will ensure that its designated abuse contact is aware of the additional sensitivities that may potentially arise with respect to use of cc.sncf or countryname.sncf domains, such that any complaints of this nature are prioritized accordingly. SNCF will not use geographic names until ICANN has approved such use.

Registry Services


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

Table of Contents :

1 - Receipt of data from registrars concerning registration of domain names and nameservers : Shared Registration System (SRS)
2 - Operation of the Registry zone servers
3 - Provision to registrars of status information relating to the zone servers for the TLD
3.1 - Standard DNS related status information
3.2 - Emergency DNS related status information
4 - Dissemination of TLD zone files.
4.1 - Incremental updates every 10 minutes
4.2 - Complete publication of the zone
4.3 - Propagation mechanism
4.4 - Zone File Access⁄Distribution
5 - Dissemination of contact or other information concerning domain name registrations (Whois service)
6 - DNS Security Extensions (DNSSEC)
6.1 - Registrar Services
6.2 - Signing Activity
7 - Other relevant services
7.1 - Security and Redundancy
7.2 - Consensus Policy Compliance


------------------------
1 - Receipt of data from registrars concerning registration of domain names and nameservers : Shared Registration System (SRS)

Operated by AFNIC, the .SNCF TLD will adapt a domain shared registration system used in production by AFNIC to operate .fr zone and which has been fully functional for the past 15 years. This Extensible Provisioning Protocol (EPP) based Shared Registration System (SRS) has exhibited the ability to meet stringent SLAs as well as to scale from the operational management of an initial thousands of domain names to over 2 million in late 2011.

The SRS exists to interact with the Registrar’s systems, who are responsible for the provisioning of a registrant’s domain name with the .SNCF TLD registry. Registrars interact with the registry through two primary mechanisms :
* Communication machine to machine via an EPP client (Registrar) to an EPP Server API (Registry).
* A Web Portal Interface that expresses the functionality of the EPP API. The Web Portal also provides access to user configuration and other back-office functions such as report and invoice retrieval.

SRS functionality includes standard functions and features such as :

* Domain Registration : The AFNIC SRS supports synchronous registrations (creations) of domain names through the EPP domain create command. It supports updates of associative status, DNS and DNSSEC delegation information and EPP contact objects with a domain and the deletion of existing domains. This allows Registrars to create domain registrations, modify them and ultimately delete them.

* Domain Renewal : The AFNIC SRS allows registrars to renew sponsored domains using the EPP renew command. The SRS automatically renews domain names upon expiry.

* Transfer : The AFNIC SRS supports the transfer of a given domain between two Registrars in a secure fashion by requiring two party confirmations and the exchange of a token (the EPP authinfo code) associated with the domain.

* Contact Objects : The AFNIC SRS supports the creation, update, association to domain objects, and deletion of EPP contact objects. This functionality supports the required information to supply contact data displayed in Registration Data Directory Services (RDDS) (Whois) systems.

* Hosts : A subordinate object of the domain object in an EPP based SRS, internal hosts are supported in the AFNIC SRS. These hosts cannot be removed when other 2nd level domains within the .SNCF TLD zone are delegated to these nameservers. Delegation must be removed prior to the removal of the child hosts and a parent domain name to a given host in turn cannot be removed prior to the deletion of the related child host.

* Redemption Grace Period (RGP) & Restoring deleted domain name registrations : AFNIC SRS supports the RGP for the purpose of retrieving erroneously deleted domain names prior to being made available again for public registration.

Other features include :

* Additional EPP commands in order to manage and update both domain and contact objects in the registry which are EPP info, check, delete and update commands.

* An inline billing system which is synchronised with the SRS. Actions can be taken daily from simple alerts to concrete account blocking.

* Grace Periods and Refunds : the AFNIC SRS will support standard grace periods such as Add, Renew, Autorenew, Transfer and RGP grace periods. Refunds issued will reflect actual values deducted from registrar’s balance in consideration of any rebates issued conjunctively or separately for the relevant domain registration.

* The capacity to deal with reserved domain name registration. Reserved names are stored in a specific back office tool. Specific authorisations codes can be delivered out of band by support team to “unlock” creation of these reserved names. SRS uses standard EPP auth_info field in conformity with EPP RFCs to prevent or allow the registration of the domain name.

[see attached diagram Q23_1_authorisation_code_workflow.pdf]
Diagram : Reserved names unlock
Description : This diagram illustrates process to unlock registration of reserved names. An out of band email process is used to deliver a specific authorisation_code, that can be used in EPP or through the web interface to register the domain name.

SRS EPP functions are compatible with the following list of RFCs :
RFCs 5910, 5730, 5731, 5732, 5733 and 5734. Since AFNIC will implement the Registry Grace Period (RGP), it will comply with RFC 3915 and the successors of the aforementioned RFCs.


------------------------
2 - Operation of the Registry zone servers

The DNS resolution service is a core business of the Registry Operator. It is an essential function that must be provided with a very high level of service quality to satisfy queries concerning a zone 100% of the time with a response time as short as possible.

As the registry back-end service provider for the .SNCF TLD, AFNIC has a set of sites, distributed internationally, to answer these queries. The high availability of responses is ensured by the number of servers that host the zone information; the response time is in turn linked to the geographical location of the servers (as near as possible to the exchange points and as a result to users).

To ensure a very high level of availability of information and a response time as short as possible to a DNS query for a given zone, AFNIC has chosen to deploy its own DNS architecture, operated by our teams, while also relying on a set of internationally recognized service providers in order to significantly increase the number of servers hosting the zone to be published.

The AFNIC DNS service is based on the standards of RFCs (RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966 and any future successors), related to the Internet, and the DNS in particular.

In addition, special attention has been paid to the security component of the DNS servers and services in order to maintain a very high level of availability of the information, for example in the event of attacks or the denial of services. At present, a series of national and international servers are deployed as close as possible to the exchange points to ensure the DNS resolution service. To ensure a high level of availability, Anycast technology is applied to overcome the issues involved in the geographical location of sensitive servers. Through an effective pooling of DNS server resources, it ensures better resistance to denial of service attacks as the number of physical servers to attack is very high, and the geographical attraction of traffic by each server is very strong. Maintenance of the nodes is also improved since interventions on a given server have no effect on the visibility of the Anycast cloud for users.
As explained in the answer to Question 34 (Geographic Diversity), the registry also relies on two operators of Anycast clouds to expand the international coverage of the DNS nodes which must respond to queries for the domain extensions hosted on them. The two operators are Netnod Autonomica and PCH (Packet Clearing House) who are both known for their high quality services; in addition, Netnod Autonomica hosts one the root server i.root-servers.net.


------------------------
3 - Provision to registrars of status information relating to the zone servers for the TLD

Registrars interactions with the Registry Systems in two states in regards to the state of the TLD zone servers :
* an operational state where normal registry transactions and operational policies⁄practices result in a cause and effect in resolution of relevant domains AND
* an emergency state where resolution could be threatened by operational problems due to either internal or external factors to the DNS services.

------------------------
3.1 - Standard DNS related status information

The SRS supports related updates to domain objects that allow a Registrar to populate internal (glue record) and or external DNS hosts associated with the domain. External hosts result in the correct associated NS records being inserted into the current TLD zone file, this in turns results in DNS resolution being delegated to the identified external hosts. The SRS expresses this status to the Registrar as “Active” in both the EPP API and the SRS Web Portal. The registrar may suspend the NS records associated with the external hosts by applying an EPP client HOLD in the system, which will also be displayed as a status in the same manner. This holds true of the Registry when it applied “Server Hold”. Internal hosts follow the same behaviour with one exception, IP addresses must also be provided to the SRS by the registrar for Internal hosts, resulting in A records or⁄and AAAA records for IPv6 (also known as glue records) being added to the zone file.

------------------------
3.2 - Emergency DNS related status information

AFNIC registry services maintain emergency Network Operation Center (NOC) and Customer Service personnel on a 24⁄7⁄365 basis to address escalation and customer issue management. Part of these teams responsibility is to maintain contact lists for technical notification of regular or emergency situations including email lists, names and contact numbers. In the unlikely event that DNS resolution or DNS updates were or were expected to fall out of ICANN mandated SLAs, registrars will be contacted proactively by their email lists, status alerts will be posted to the Registry Operator’s Registrar Relations Web Portals and Customer Service personnel will be prepared to take and address calls on the current DNS status.


------------------------
4 - Dissemination of TLD zone files.

Publication of DNS resolution data to the TLD DNS nodes serving resolution :
One of the main challenges of DNS resolution is to provide updated information about the resources associated with a registered domain name. As soon as information is updated by a registrar on behalf of a customer, the latter expects the server to be accessible to its users as soon as possible.
For this reason, updates of DNS resolution data (publication) are entered into the AFNIC SRS, subsequently generated into incremented zone files, and are distributed to the authoritative DNS servers using the two following methods :
* Incremental updates every 10 minutes
and
* Complete publication of the zone.

------------------------
4.1 - Incremental updates every 10 minutes

The principle of publication by Dynamic Update (RFC 2136 and 2137) is designed to publish only the changes to the zone that have occurred since the last update. At the registry level, we have opted to propagate every 10 minutes the changes made during the last 10 minutes on all the zones managed. In this way, any changes made will naturally be published in the next 10 minutes.

------------------------
4.2 - Complete publication of the zone

In addition to the publication described above, the registry’s DNS operations team produces a complete publication of all the data for all the zones once a week by running a series of computer scripts which regenerates zonefile from database, through the same validation and integrity mechanisms as dynamic publication. This is used as a training for eventual recovery measures to be triggered.

------------------------
4.3 - Propagation mechanism

Whether during the publication by Dynamic Update or complete publication, the propagation mechanism is the same. The process involving the generation of the various zone files is triggered, without blocking any operation on the registration system.
These zone files are then transmitted in full to the authoritative server, via the AXFR protocol in conformance with RFC 5936. Once received and processed by the authoritative server, notifications are sent to secondary servers that will retrieve the changes in the different zones via the IXFR protocol in conformity with RFC 1995. The choice of an incremental (rather than complete) update of the zone files to the secondary servers during the dissemination process has been made to avoid sending large amounts of data to remote sites.

------------------------
4.4 - Zone File Access⁄Distribution

In compliance with Specification 4, Section 2, AFNIC registry services will offer a subscription service for qualifying applicants to download a stateful copy of the TLD zone file no more than once per 24 hours period. Distribution of the zone file will occur through the ICANN authorized Centralized Zone Data Access Provider.


------------------------
5 - Dissemination of contact or other information concerning domain name registrations (Whois service)

The AFNIC RDDS (Whois) service is in direct connection with the database of the Shared Registration System and offers access to the public administrative and technical data of the TLD. Contact data associated with registrations in the SRS is accessible both on port 43 (following specifications of RFC 3912) and through web access.

Data that can be accessed through the RDDS include:
* contact data : holder, administrative, technical, billing
* domain data : domain name, status
* host data : name servers, IP addresses
* ephemeris : creation, expiration dates
* registrar data
These data elements are fully compliant to the mapping of RFCs 5730 to 5734 and an example of standard port 43 output is given at the end of answer to Question 26 (WHOIS).

Both web and port 43 RDDS offer natively compliance with privacy law with a “restricted diffusion” flag. This option is activated through EPP (see Question 25 (EPP)) while creating or updating a contact and automatically understood by the Whois server to anonymize the data. The choice to activate restricted diffusion is made in compliance with the policy and the local rules of the TLD.

This service is accessible both in IPv4 and IPv6. The AFNIC RDDS service access is rate limited to ensure performance in the event of extreme query volumes generated in the cases of distributed denial of service (DDOS) and⁄or RDDS data-mining activities.


------------------------
6 - DNS Security Extensions (DNSSEC).

AFNIC registry services fully support DNSSEC and will sign the .SNCF TLD zone from initiation into the root servers.

------------------------
6.1 - Registrar Services

Operations are available for registrars through EPP with the SecDNS EPP extension version 1.1 exclusively (as defined in RFC 5910) or through registrars extranet (with a web form). Among the two interfaces defined in the RFC 5910, AFNIC chose the “dsData” interface : domain names keys are solely under registrars management and are not exchanged, only the keys hashes (DS records) are sent by the registrars to the registry back-end service provider. Each domain name can be associated to 6 distinct key materials at most.

Zonecheck : A complementary monitoring and validation service.
AFNIC notes that “Zonecheck” is a DNS monitoring and validation service that is outside standard registry services and could be offered by third parties other than a Registry Operator. In respect of DNSSEC monitoring, each change of DS data related to a domain name is verified by the AFNIC ZoneCheck tool, out of band of standard EPP registry functions. Registrar are notified via email of detected errors. This helps Registrars ensure the DNSSEC validation will operate correctly, for example by avoiding the “Security Lameness” scenario outlined in section 4.4.3 of RFC 4641.

Registrar transfer by default removes DS data from the zonefile. This is done to cover cases when a current signed domain names goes from a DNSSEC enabled registrar to another registrar that is not yet prepared to handle DNSSEC materials (the registrar can also be the DNS hoster or not, but in both cases DS data of the domain name has to flow from the registrar to the registry, hence the registrar must have the technical capabilities to do so).

------------------------
6.2 - Signing Activity


Each public-facing DNS server operated by AFNIC or through its anycast providers is fully DNSSEC enabled through RFC 4033, 4034, and 4035 by virtue of using standard open source software (BIND & NSD) that are developed according to these RFCs.

Each zone uses a standard Key Signing Key (KSK)⁄Zone Signing Key (ZSK) split (as defined in RFC 4641, section 3.1), which enables longer KSKs and frequent re-signing of zone content to deter DNSSEC-related brute force attacks and to make sure that keys rollovers are part of registry staff operational habits. All keys are created using RSA algorithms, as defined in RFC 4641 section 3.4 : KSKs are 2048 bits long (as recommended for “high value domains” in section 3.5 of RFC 4641), and ZSKs are 1024 bits. Algorithm SHA-256 (as defined in RFC 4509) is used for DS generations. Signatures of zone resources records are done using SHA-2 and more specifically RSA⁄SHA-256 as defined by RFC 5702.

Each zone has its set of dedicated KSKs and ZSKs: one of each is active at all time, while a second of each is ready to be used at next rollover. A third ZSK may be kept in the zone after being inactive (not used any more for signing) to ease transitions and make sure DNS caches can still use it to verify old resource records signatures. Following recommendations in section 4.1.1 “Time considerations” of RFC 4641, with a zone maximum TTL being 2 days and a zone minimum TTL of 1.5 hour, ZSK rollovers are done each 2 months, KSK rollovers are done each 2 years. Their expirations are monitored. Rollovers are operated according to the “Pre-Publish Key Rollover” procedure detailed in section 4.2.1.1 of RFC 4641.

1 year worth of key materials is generated in advance. Encrypted backup of keys is made on Hardware Security Module (HSM) cards (Storage Master Key), which are securely stored physically.


------------------------
7 - Other relevant services

------------------------
7.1 - Security and Redundancy

AFNIC maintains primary and secondary datacenter locations as well as redundant key personal operating locations. High availability of AFNIC Registry infrastructure is provided through the implementation of either load‐balancing, or fail­‐over capacity in various layers of the architecture. It also enables fast scalability through expertise in virtualization technologies. AFNIC’s infrastructure is globally virtualized apart from services requiring very high performance rate and⁄or specific access to dedicated CPU for demanding computation such as DNSSEC zone signing or databases.
AFNIC maintains robust secure policies, protocols and third party testing and certification of security measures and practises. Systems involved in the AFNIC registry services used standard multi-factor authentication, high encryption transmission of data and are kept current with industry advancement in security technologies and best practices in prevention of data breaches. Registry systems follow standard EPP practices including required passphrases associated with each domain object and the use of those passphrases to successfully negotiate and verify domain transfers. Registrars are networked source restricted (2 IP addresses authorized by registrar) for SRS access in addition to the use of digital certificates and contact to Customer Service is restricted to registered Registrar personnel only (identified by personal passphrases⁄credentials listed on file).

------------------------
7.2 - Consensus Policy Compliance

AFNIC registry services will fully comply with Specification 1 of the Application Guidebook, below is a list of current consensus policies that have cause and effect on the systems of a registry operator. This list will be updated from time to time as per the ICANN process and the AFNIC registry services will be adjusted to maintain and support full compliance.

* Uniform Domain Name Dispute Resolution Policy (adopted by ICANN Board 26 August 1999; form of implementation documents approved 24 October 1999).
* Inter-Registrar Transfer Policy (effective on 12 November 2004, adopted by ICANN Board 25 April 2003; implementation documents issued 13 July 2004).
* Registry Services Evaluation Policy (effective on 15 August 2006, adopted by ICANN Board 8 November 2005; implementation documents posted 25 July 2006)
* AGP Limits Policy (effective on 1 April 2009, adopted by ICANN Board on 26 June 2008; implementation documents posted 17 December 2008)

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

Table of Contents

1 - Global description
2 - Shared Registration System (SRS) architecture
3 - SRS architecture diagram
4 - Detailed infrastructure
5 - Rate limitation
6 - Interconnectivity and synchronization with other systems
7 - Performance and scalability
8 - Resources
8.1 - Initial implementation
8.2 - On-going maintenance


------------------------
1 - Global description

As one of the critical registry functions, the SRS is part of the core of AFNIC back-end registry solution as deployed to fit the needs of the .SNCF TLD.
It both provides services for registrars and generates the data used for DNS publication and resolution service. In that aspect, it is responsible for most of the SLA’s to be respected. The following description will provide full and detailed description of the architecture of the SRS both from an application and from an infrastructure point of view.
This architecture is the same as the one used in production by AFNIC to operate .fr zone and has been fully functional for the last 15 years, with the ability to meet stringent SLAs as well as to scale from the management of a few thousands domain names in operations to over 2 million in late 2011.


------------------------
2 - Shared Registration System (SRS) architecture

AFNIC SRS is based on a three-layer architecture : front-end, business logic, middleware.
These three layers are supported by the data layer which is described in detail in Question 33 (Database Capabilities).

= Front end : Extensible Provisioning Protocol (EPP) and extranet =

The automated front-end of the SRS is EPP.
The EPP interface and implementation complies with RFCs 3735 and 5730-5734. It is itself described in detail in Question 25 (EPP).
An extranet web interface also offers the same functions as the EPP interface.
Both theses interfaces are supported by the same middleware layer.

= Business logic : flexible policies =

The Business logic enables configurability in order to allow for the adjustment of registry systems to the chosen registry policies. Various policy-related parameters such as delay for redemption, access rate-limiting and penalties can be configured in this layer.
The Business logic also incorporates a scheduler which provides for semi-automated processes with human validation in order to address specific policy needs which cannot or should not be fully automated.

= Middleware : a guaranty for evolution and scalability =

The Middleware layer guarantees a consistent and registry oriented access for all the TLD data. All registry applications operate through this layer in order to centralize object management rules. It enables access through different programming languages (Java, php and Perl in AFNIC solution) with same rules and ease of switching from one language to another in case of application refactoring or migration.

= Data =

The Data layer is the structured data repository for domain, contact, operations, historization of transactions, as well as registrars and contracts data. It provides all the necessary resilient mechanisms to ensure 100% uptime and full recovery and backup.
It also provides a complete toolbox for the fine tuning of the various applications. This layer is described in more details in Question 33 (Database capacities).


------------------------
3 - SRS architecture diagram

[see attached diagram Q24_3_SRS_architecture_diagram.pdf]
Diagram : SRS architecture diagram
Description : This diagram shows global interaction between Internet, DMZ (Demilitarized Zone) and private network zones. Topology of network and servers is illustrated including dedicated IP address scheme and network flows.

This diagram does not shows additional sandbox and preproduction services. These services are offered respectively for registrars and back-end developer team to stabilize developments before production delivery. They are fully iso-functional to the SRS description above.

= SRS logical diagram =

Our robust infrastructure shows dual Internet Service Provider (ISP) connectivity both in IPv4 and IPv6 (Jaguar and RENATER), redundant firewall and switching infrastructure. This part of the architecture is mutualised for all TLDs hosted.

The networking architecture dedicates LAN for administration, backup and production.

Servers are hosted on different network zones : database for database, private for servers not visible on the internet and public for external servers visible on the DMZ. Dedicated zones are also set up for monitoring servers, administration servers or desktop and backup servers.
Each server is load balanced and the service is not impacted by the loss of one server, the capacity of each server being sized to be able to host the whole traffic.

Servers hosting the .SNCF TLD are shared with up to an estimated number of 20 TLDs of comparable scale and use case.

Refer attached SRS physical diagram

The IP scheme used is the following :

2001:67c:2218:1::4:0⁄64 for IPv6 Internet homing
192.134.4.0⁄24 for Ipv4 Internet homing

Production LAN

192.134.4.0⁄24 for public network IP range
10.1.50.0⁄24, 10.1.30.0⁄24 for private network IP ranges distributed on the zones described above.


Backup LAN

172.x.y.0⁄24 : x is different on each network zone. y is fixed to the value of the associated production LAN in the same zone (for example Private zone production LAN being 10.1.”50”.0⁄24, Private zone backup LAN is 172.16.”50”.0⁄24)

Administration LAN

172.z.y.0⁄24 : z is the value of x+1, x being the digit chosen for the corresponding Backup LAN in the same zone. y is fixed to the value of the associated production LAN in the same zone (for example Private zone production LAN being 10.1.”50”.0⁄24, Private zone administration LAN is 172.17.”50”.0⁄24).

Hot standby of the production database is automatically taken into account by the SRS Oracle Transparent Network Substrate configuration. Therefore if the database are migrated in hot standby due to failure of part of the system, the SRS access is automatically swapped to the new base.


------------------------
4 - Detailed infrastructure

The SRS modules play a central role in the back-end registry infrastructure. This is highlighted in terms of capacity expenditures (CAPEX) by the fact that SRS modules account for approximately 30% of the global CAPEX of the solution.

In the following description “server” will refer to either a physical or a virtual server.
Due to very fast growth of performance in storage and processors technologies, the infrastructure described below could be replaced by more powerful one available at the time of the set up for the same cost.

At the applicative and system level, AFNIC’s SRS systems are shared with up to an estimated number of 20 TLDs of comparable scale and use case.

AFNIC has invested in very efficient VMWare Vsphere virtualization infrastructure. It provides a flexible approach to recovery both through quick activation of a new fresh server in case of local failure (cold standby) and through global failover to a mirrored infrastructure on another site.
This comes in addition to natural redundancy provided by the load balanced servers.

Nevertheless, internal protocols and best practices for server virtualization have shown that very high I⁄O-intensive (Input⁄Output) application servers are not good clients for virtualization. The SRS is therefore hosted on virtualized infrastructure to the exception of the database, which presents very high rate of I⁄O, and is hosted on a dedicated physical infrastructure.

The whole SRS service is located in the primary datacenter used by AFNIC in production, the secondary datacenter serves as failover capacity.

The Front end is hosted on two load balanced virtual servers and two load balanced reverse proxies ensuring authentication of registrars.

The Business logic is hosted on two load balanced dedicated virtual servers. Scalability of these servers is ensured by quick resizing offered by virtualization technology if needed.

The Middleware is hosted on two load balanced dedicated virtual servers. It can be extended to any amount of servers needed to ensure performance commensurate with the amount of traffic expected. The dual use of Apache HAproxy and of a centralized lock mechanism ensure good queuing of each request in the system despite heavy load and parallelized middleware data access.

Scalability of all these servers are ensured by quick resizing offered by virtualization technology if needed.

All databases are based on Oracle technologies. The main database is replicated logically on two sites. Full local recovery processes are in place in case of loss of integrity through the Oracle redolog functions which provides full recovery by replay of historized logged requests.

The whole SRS service is located in the primary Tier 3 datacenter used by AFNIC in production, the secondary datacenter serves as failover capacity. Continuity mechanisms at a datacenter level are described in Questions 34 (Geographic Diversity), 39 (Registry Continuity) and 41 (Failover testing).

The detailed list of infrastructures involved can be described as follows :

This infrastructure is designed to host up to an estimated number of 20 TLDs of comparable scale and use case.

= Virtual servers =

EPP proxy : 2 servers
* Processor: 1 bi-core CPU
* Main memory: 8 GB of RAM
* Operating system: RedHat RHEL 6
* Disk space: 500 GB

EPP service : 2 servers
* Processor: 1 quad-core CPU
* Main memory: 16 GB of RAM
* Operating system: RedHat RHEL 6
* Disk space: 1 TB

Business logic : 2 servers
* Processor: 1 bi-core CPU
* Main memory: 16 GB of RAM
* Operating system: RedHat RHEL 6
* Disk space: 500 GB

Data Gateway : 2 servers
* Processor: 1 quad-core CPU
* Main memory: 16 GB of RAM
* Operating system: RedHat RHEL 6
* Disk space: 1 TB

= Data storage : see Question 33 (Database Capabilities) =

= Physical server =

Rate limiting database : 1 server
* Processor: 1 bi-core CPU
* Main memory: 8 GB of RAM
* Operating system: RedHat RHEL 6
* Disk space: 500 GB

Back up servers, backup libraries, Web whois server : mutualized with the global registry service provider infrastructure

= Additionnal infrastructure =

Failover infrastructure : 6 servers
* 1 bi-core CPU, 8 GB of RAM, RedHat RHEL 6, 500 GB

Sandbox infrastructure : 6 servers
* 1 bi-core CPU, 8 GB of RAM, RedHat RHEL 6, 500 GB

Preproduction infrastructure : 1 server
* 1 quad-core CPU, 16 GB of RAM, RedHat RHEL 6, 1 TB


------------------------
5 - Rate limitation

To ensure resiliency of the SRS a rate limitation and penalty mechanisms are in place.
Rate limitation and penalties are directly implemented on the front end server.

Access is rate limited through token-bucket algorithms with rate-limiting IP data stored on a dedicated database.
Penalties are applied as follow :
* Any command that follows a login command is immediately executed but the next one is only taken into account 2 seconds later. The following commands are not penalized (unless they do not follow one of the limitation rules).
* For the same domain name, the domain:check commands will not be able to follow themselves more than 2 times every 4 seconds. Beyond this rate, a 2 second penalty will be applied on the following domain:check commands (for the same domain name). For instance, it is possible to have a domain:check follow a domain:create command that already followed a first domain:check on a same domain name without any penalty.
* On the other hand, a customer making several domain:check commands on a same domain name will need to respect a 4 second delay between the first and the third call if he wishes not to be penalized.
* Any domain:create command on an already existing domain name induce an additional 2 seconds in the answer time of this command.
* Any domain:info command on a domain name that is not in your portfolio and for which you do not indicate the auth_info induce an additional 1 second in the answer time of this command.

The rate limiting database is hosted on one physical dedicated physical server. This server represents no failure point as a failure of the rate limiting system doesn’t affect the service (a standard uniform limitation is then applied instead of intelligent rate limiting).


------------------------
6 - Interconnectivity and synchronization with other systems

= Whois (RDDS) =

The whois service will be described in detail in question 27. It is hosted on two servers directly connected to the main production database through read only API. Data updated by the SRS are immediately visible in the Whois with no further synchronisation needed. Rate limitation is applied on RDDS service to avoid any load on the database due to Whois direct access. Hot standby of the production database is automatically taken into account by the Whois Oracle Transparent Network Substrate configuration. Therefore if SRS and database are migrated in hot standby due to failure of part of the system, the Whois service is automatically swapped to the new architecture.


= Back office⁄billing⁄Escrow =

Back-office, escrow and billing system is hosted on mutualized server. It operates directly on production data through the middleware layer to ensure integrity of data. These can be considered as fully synchronous applications. Hot standby of the production database is automatically taken into account by the Middleware layer Transparent Network Substrate configuration. Therefore if SRS and database are migrated in hot standby due to failure of part of the system, the back office and billing service are automatically swapped to the new architecture.


= Monitoring =

Monitoring is operated through probes and agents scanning systems with a 5 minutes period. The monitoring system gets snmp data from all servers described in the SRS architecture and also from dedicated Oracle monitoring agent for the database. A specific prove for EPP simulating a full domain creation is also activated, still with the 5 minutes period.

= Dispute resolution =

Any operation on domain names triggered in the context of a dispute resolution is made through a back-office tool (see Back office)

= DNS publication =

DNS publication relies on a specific table of the production database hosted on the same oracle instance. These data are directly generated by the SRS system. Dynamic Update batches are generated at each operation. The use of theses batches for DNS Dynamic update or of the whole data for full zonefile generation are made directly from these production data. No further synchronization is needed. The detail of frequency and workflow for dns publication is described in Question 35 (DNS) and Question 32 (Architecture). Hot standby of the production database is automatically taken into account by the DNS publication Transparent Network Substrate configuration. Therefore if SRS and database are migrated in hot standby due to failure of part of the system, the dns publication is automatically swapped to the new architecture.


------------------------
7 - Performance and scalability

The Registry’s SRS offers high level production SLAs and derives from the branch of systems that have evolved over the last 15 years to successfully operate a set of french ccTLDs.

The Registry’s SRS is used to operate .fr, .re, .yt, .pm, .tf, .wf TLDs. It is used by more than 800 registrars in parallel managing more than 2 millions domain names.

AFNIC’s SRS is designed to meet ICANN’s Service-level requirements as specified in Specification 10 (SLA Matrix) attached to the Registry Agreement.

Actual and current average performance of AFNIC’s SRS is :
* SRS availability : 99,4%
* SRS session-command RTT : 400ms for 99,4% of requests
* SRS query command RTT : 500ms
* SRS transform command RTT : 1,4 s on availability period
* SRS max downtime : 2 hours⁄month

As described in Question 31 (Technical Overview) in relation to each of the phases of the TLD’s operations, the following transaction loads are expected on the SRS :
* launch phase : up to 400 queries⁄second
* routine ongoing operations : up to 2,000 queries⁄second

The system is designed to handle up to 50,000 domain names and up to 2 requests per second.

The targeted TLD size being approximately 4,000 domain names after 3 years of operations and the expected peak transaction rate being 2,000 queries⁄second this ensures that enough capacity is available to handle the launch phase, unexpected demand peaks, as well as rapid scalability needs.

Capacity planning indicators are set up to anticipate exceptional growth of the TLD.
Technologies used enables quick upgrade on all fields :
* Servers : virtual resizing to add CPUs or disk space if resource is available on the production ESX servers. If not, 2 spare additional ESX servers can be brought live if additional performance is needed.
* Database : database capacity has been greatly oversized to avoid need of replacement of this physical highly capable server. Precise capacity planning will ensure that sufficient delay will be available to acquire new server if needed. A threshold of 40% of CPU use or total storage capacity triggers alert for acquisition.


------------------------
8 - Resources

Four categories of profiles are needed to run the Registry’s Technical Operations : Registry Operations Specialists (I), Registry Systems Administrators (II), Registry Software Developer (III) and Registry Expert Engineers (IV). These categories, skillset and global availability of resources have been detailed in Question 31 (Technical Overview of Proposed Registry) including specific resources set and organisation to provide 24⁄7 coverage and maintenance capacity.
Specific workload for SRS management is detailed below.

------------------------
8.1 - Initial implementation

The set up is operated on the pre-installed virtualization infrastructure. It implies actions by system, database and network administrators to create the virtual servers and install the applicative packages.

Then, developers, assisted by a team of experts and senior staff members apply proper configuration for the given TLD. Specific policy rules are configured and tested.

The initial implementation effort is estimated as follows :

Database Administrator 0.03 man.day
Network Administrator 0.03 man.day
System Administrator 0.03 man.day
Software Developer 0.10 man.day
Database Engineer 0.10 man.day
Software Engineer 0.20 man.day
DNS Expert Engineer 0.10 man.day

------------------------
8.2 - On-going maintenance


On-going maintenance on the SRS includes integration of new policy rules, evolution of technology, bug fixing, infrastructure evolution, failover testing.

Although all the defined technical profiles are needed for such on-going maintenance operations, on a regular basis, it is mainly a workload handled by monitoring and development teams for alert management and new functional developments, respectively.

The on-going maintenance effort per year is estimated as follows, on a yearly basis :

Operations Specialist 0.40 man.day
Database Administrator 0.10 man.day
Network Administrator 0.10 man.day
System Administrator 0.10 man.day
Software Developer 0.20 man.day
Database Engineer 0.05 man.day
Network Engineer 0.05 man.day
System Engineer 0.05 man.day
Software Engineer 0.05 man.day

25. Extensible Provisioning Protocol (EPP)

Table of Contents

1 - Global description
2 - Description of commands
2.1 - Introduction
2.2 - Global commands
2.2.1 - session management commands ‘greeting’, ‘hello’, ‘login’, ‘logout’
2.2.2 - poll command ‘poll’
2.3 - domain commands
2.3.1 - query commands ‘check’, ‘info’
2.3.2 - transform commands
2.4 - contact command
2.5 - Return Codes
3 - Compliance to RFCs
3.1 - Delivery process
3.2 - XML validation
3.3 - Cross checking
4 - Specific extensions
4.1 - Specific extension : DNSSEC
4.2 - Specific extension : IDN
4.3 - Specific extension : Sunrise period
4.3.1 - New objects
4.3.2 - command extensions
4.3.2.1 - EPP Query Commands
4.3.2.2 - EPP Transform Commands
4.3.2.2.1 - EPP ʹcreateʹ Command
4.3.2.2.2 - EPP ʹupdateʹ Command
4.3.2.2.3 - EPP ʹdeleteʹ Command
5 - Resources
5.1 - Initial implementation
5.2 - On-going maintenance


------------------------
1 - Global description

The main service of the Shared Registration System (SRS) for its registrars is the Extensible Provisioning Protocol (EPP) interface. The interface has been developed and is maintained in full compliance with the relevant standards RFCs 5730-5732 and with RFCs 5910 and 3735 for the standard registration interface. Contacts are handled as described in RFC 5733. Transport is guaranteed according to RFC 5734. In addition, AFNIC’s EPP implementation is also compliant with RFCs 4034, 5730 and 5731 for DNSSEC support and with RFCs 5890 and 5891 for Internationalized Domain Name (IDN) support.

The EPP service is available through IPv4 and IPv6, based on a SSL certificate authentication.
No specific extension is used.

Note : Throughout the document we write the XML markups describing the EPP requests between the two characters ʹ and ʹ.

For contact management, the registry service provider uses a dedicated “Repository Identifier” for each TLD, this Repository identifier being declared to IANA prior to the launch of the TLD. It is also used as a post-extension to contact nic-handles, each contact for a given TLD being then identified by a unique code XX1234-REPID. An example of this declaration can be found for .fr extension (2008-05-10) at IANA epp repository identifier’s page :

[...]
NORID, #x004E #x004F #x0052 #x0049 #x0044 UNINETT Norid AS 2007-12-10 info&norid.no
FRNIC, #x0046 #x0052 #x004e #x0049 #x0043 AFNIC 2008-05-29 tld-tech&afnic.fr
CIRA, #x0043 #x0049 #x0052 #x0041 Canadian Internet Registration Authority 2009-07-22 info&cira.ca
[...]


------------------------
2 - Description of commands

------------------------
2.1 - Introduction

The EPP interface, based on a double system of real-time answer by the server and asynchronous notifications, implements all standard operations : ‘domain:create’ (1 to 10 years), ‘domain:info’, ‘domain:checkʹ, ‘domain:transfer’, ‘domain:update’, ‘domain:renew’. Similar commands are available concerning contact objects.
The registry’s EPP server implement name servers management as domain name attributes in conformity with RFC 5732.

[see attached diagram Q25_2.1_EPP_xsd_main_schema.pdf]
Diagram : EPP xsd main schema
Description : Registry service provider SRS EPP interface is based on standard xsd schema as defined in RFC 5730.

In the following description of the commands, an example of client command and server answer has been added only for the create command as an example. All other commands work in the same way in full compliance with descriptions and schema of RFCs 5730-5734 and same examples can be found in the RFCs text.

------------------------
2.2 - Global commands

------------------------
2.2.1 - session management commands ‘greeting’, ‘hello’, ‘login’, ‘logout’

As all of these commands are basic and totally compliant with the IETF’s STD69 (RFCs 5730 to 5734), they have not be described again here.

Focus points are :
* Enforcing a limit of 2 simultaneous connection per registrar (checked at login), ensuring equitable access for all registrars.
* List of namespaces announced in ʹgreetingʹ is strictly checked in registrar ʹloginʹ command.
* ʹhelloʹ can be used by registrars as a keepalive command, otherwise inactive sessions are closed by server after 20 minutes.

------------------------
2.2.2 - poll command ʹpollʹ

For some operation on objects, notifications are added in a queue that can be read by using the ʹpollʹ command. The use of the ʹpollʹ command will retrieve the oldest message in the queue. The number of messages awaiting in the queue is indicated at each command answer with the ʹmsgQʹ element. To delete a message from the queue, the ʹpollʹ command should be used with the message number as indicated in RFC 5730.

------------------------
2.3 - domain commands

------------------------
2.3.1 - query commands ʹcheckʹ, ʹinfoʹ

ʹcheckʹ command allows the client to check if a domain object is available.
ʹinfoʹ command allows the client to retrieve information on any objects (domain names or contacts) that are indicated in the command. Registrars can only use this command for objects they already manage in their portfolio. This command can also be used for domain names outside the registrar’s portfolio if the ʹauth_infoʹ code that protects the domain is given as well.

------------------------
2.3.2 - transform commands

In compliance with RFCs 5730 (commands presentation), 5731 (domain objects), 5732 (contact objects) and 5910 (DNSSEC specifications) AFNIC’s Registry solution use the following commands that allow for objects updates :

= ʹcreateʹ =

The EPP protocol (RFC 5730) allows domain name creation (RFC 5731). The registry service provider allows two types of creations: direct domain creations (with auth_info freely determined by the registrar) and domain names creation “with authorization code” (the correct auth_info value must be sent for the creation to succeed)

Both are standard domain:create command as defined in the RFCs.

[see attached diagram Q25_2.3.2_EPP_client_create_command_example.pdf]
Diagram : EPP client create command example
Description : This is a standard EPP client create command following RFC 5731. Parameters sent in the following example are domain name, period of registration, registrant identifier, administrative, technical and billing identifier, and auth_info password.

Creation “with authorization code” enables the registry service provider to manage protected names or names under specific registration conditions. An authorization code is associated to three items (the registrar, the domain name and the holder nic-handle ) and is delivered outside the automated process through a manual process defined by a specific policy rule. The registry-generated authorization code must be present in the ʹdomain:authInfoʹ item of the creation request. No registrar-computed value is permitted.
In every case, domain creation proceeds through standard EPP command.

[see attached diagram Q25_2.3.2_EPP_server_create_answer_example.pdf]
Diagram : EPP server create answer example
Description : This is a standard EPP server create command answer following RFC 5731. Parameters sent in the following example are result code, message, creation and expiry date, and client and server transaction ID.

[see attached diagram Q25_2.3.2_SRS_authorisation_code.pdf]
Diagram : SRS authorisation code
Description : The EPP auth_info field that can usually be freely filled in by the registrar has a specific use for registration of reserved names : an authorisation_code is delivered through an out of band process and must be used in the create command for the answer to be successful.

= ʹupdateʹ =

The registry offers EPP ʹdomain:updateʹ command to :
* update the administrative, technical, registrant contacts of a domain name
* update the DNS and DNSsec configuration of a domain name
* update the status of a domain name or its auth_info

This command is also used to add or delete signed delegations (DS records), through a ʹsecDNS:updateʹ extension if DNSSEC operations are wanted and if the secDNS extension was chosen by the client at login.

When requested the status of domain name is changed to “pendingUpdate”.

= ʹdeleteʹ =

The whole deletion process (including redemption grace period and pending delete) of a domain name comes with a restoration mechanism (restore). This mechanism, based on RFC 3915, is applied to the deletion operation only.

The status of the domain name is switched to ʺpendingDeleteʺ for the total duration of the ʺredemption grace periodʺ and as long as the domain is not restored or totally deleted.

= ʹtransferʹ =

The registry offers standard EPP ʹdomain:transferʹ command to allow a change of registrar to the registrant.

A transfer can be initiated only by an incoming registrar and using the auth_info that the registrant has given him. This standard mechanism acts as a security and associates the triggering of transfer to the acceptance of the owner of the domain.
The transfer operation can be triggered only if the domain is not protected by a clientTransferProhibited lock.

The transfer implementation follows RFC 5730 section 2.9.3.4 and its lifecycle follow the inter registrar transfer policy as revised by the ICANN in 2008.

------------------------
2.4 - contact command

Postal addresses are managed as indicated in RFC 5731 with the following specific rules : only the type “loc” for postal addresses is accepted and only one element of type ʹcontact:postalInfoʹ can be indicated for the contact .

ʹdiscloseʹ parameters is implemented and enables to activate restricted publication in the RDDS.
The choice to activate restricted diffusion is made in compliance with the policy and the local rules of the TLD towards privacy law.

------------------------
2.5 - Return Codes

Some operations under normal working conditions of the SRS will answer with a 1000 return code. Otherwise, two different levels of return codes have been chosen according to the two different types of problems that can happen on the SRS :
* minor problems answer with Return code 1001 : Minor problems do not affect requests reception. This code indicates the command was taken into account but that its complete execution is delayed. The final result will be known later on and will be sent in a message placed in the notification queue of the concerned registrar(s).
* blocking problems answer with Return code 2400 “command failed” : no operations that transform a domain name can be taken into account.

------------------------
3 - Compliance to RFCs

The system has been launched compliant with RFCs. Mechanisms are in place to ensure that ongoing maintenance and new functional delivery stay compliant with RFCs.

------------------------
3.1 - Delivery process

The SRS evolutions are developed on the development environment.
The development process implies strict coding rules and use of shared best practices. Pair programming is standard practice. Unit test are developed prior to function development to ensure resiliency of the produced code.

Delivery process take place in four steps :
* 1st step : XML validation and RFC compliance is checked through automated tools. A 100% compliance signal must be received to be able to proceed to second step.
* 2nd step : delivery to the pre-production environment. The development is delivered on the preproduction environment. This environment is available for internal testing team. They proceed through a standard Operational Test which goes through a full lifecycle of a domain name. Specific tests are made on new functions in any.
* 3rd step : delivery to the sandbox environment. This sandbox environment is opened for registrar where they have two accounts to validate their clients before production activation.
* 4th step : the new release is delivered in production.

------------------------
3.2 - XML validation

EPP RFC compliance is reached through three mechanisms :
* a batch of unitary tests on each operation, each answer of the server being validated through the XSD schema.
* XML validation through perl XML::LibXML::Schema library
* fuzzy testing, by sending garbage input and checking error return codes.

------------------------
3.3 - Cross checking

EPP cross checking partnership is established with .at Registry operator to validate in sandbox environment prior to delivery in production through mutual agreement.

------------------------
4 - Specific extensions

------------------------
4.1 - Specific extension : DNSSEC

The EPP server provides the secDNS-1-1 extension as described in RFC 5910. Implementation specifications are as follows :
* The server only supports “the DS data interface” (ʹsecDNS:dsDataʹ); section 4.1 of RFC 5910, without information on the associated key (the ʹsecDNS:keyDataʹ element is not included); if information on the key is indicated the server will answer with a 2102 error code.
* DNSSEC elements are only accepted during an update operation request. If included during a create operation the server will answer with a 2103 error code.
* Each domain name can have up to 6 associated DS records : the number of elements ʹsecDNS:dsDataʹ present in the ʹsecDNS:addʹ section during an update operation is therefore limited in order to have the domain name’s final status with no more than 6 DS records.
* The maxSigLife attribute is not supported, its presence inside a client request will generate a 2102 error code.
* The urgent attribute is not supported, its presence inside a client request will generate a 2102 error code.

[see attached diagram Q25_4.1_EPP_xsd_dnssec_extension_schema.pdf]
Diagram : EPP xsd dnssec extension schema
Description : Registry service provider DNSsec EPP secDNS-1-1 extension is based on standard xsd schema as defined in RFC 5910.

------------------------
4.2 - Specific extension : IDN

No specific IDN extension has been used. The script used for the TLD is declared in the greetings and no further indication is needed in the following transaction. Usage is in full compliance with RFCs 5890, 5891, 5892, 5893, and 5894. This may be a pending situation : if a standard IDN extension was to be produced in the months to come it would be added to the EPP schema in order to deal more precisely with each specific language management policies.

------------------------
4.3. Specific extension : Sunrise period

Sunrise period is managed through a specific EPP extension. The sunrise registration workflow is described in Question 29 (Right Protection Mechanism).

The extension used is described below but will follow work in progress at the IETF initiated by Cloud Registry (draft-tan-epp-launchphase-01.txt). The xsd schema has been designed by AFNIC’s partner CORE and is fully in accordance with the draft. It could be modified before the launch if the IETF draft was to be accepted as an RFC with modifications.

AFNIC Registry extension is fully compatible with extension mechanism described in RFC 5730. It offers trademark holders a specific mapping to provide information related to trademarks. It also enables query function to keep the sunrise process transparent to everybody.

For illustration and further information purposes, please refer to the Q25_4.3_EPP_xsd_sunrise_extension_schema.pdf file attached (EPP XSD sunrise extension schema) which describes the registry back-end services provider’s EPP extension XSD schema used to deal with sunrise period. This schema is designed based on the work in progress at IETF, as initiated by Cloud Registry (draft-tan-epp-launchphase-01.txt). This extension is fully compatible with extension mechanism described in RFC 5730.

------------------------
4.3.1 New objects

application : to deal with multiple demands on same domain name. The server creates an application object corresponding to the request and assigns an identifier for the application and returns it to the client. This mapping defines an ʹlp:applicationIDʹ element which is used to specify an ID to this object.

phase : optionnal element ʹlp:phaseʹ to be used in case of multiple sunrise phases.

status : status of each application in link with internal state of the process of the application. The ʹlp:statusʹ values that can be used in order to process the applications are pending, invalid, validated, allocated, rejected. These statuses have to be mapped with the sunrise workflow described in Question 29 (Right Protection Mechanism).

claim : claim object contains the details needed to applicantʹs prior right to the domain name.
The ʹlp:claimʹ element has the boolean ʺpreValidatedʺ attribute, which indicates whether a third party validation agency has already validated the claim in case of inter connection with the IP clearing house.

Several child elements of the ʹlp:claimʹ element are defined :
ʹlp:pvrcʹ, the Pre-Validation Result Code, is a string issued by a third-party validation agent. ʹlp:claimIssuerʹ contains the ID of a contact object (as described in RFC 5733) identifying the contact information of the authority which issued the right (for example, a trade mark office or company registration bureau).
ʹlp:claimNameʹ identifies the text string in which the applicant is claiming a prior right. ʹlp:claimNumberʹ contains the registration number of the right (i.e. trademark number or company registration number).
ʹlp:claimTypeʹ indicates the type of claim being made (e.g. trademark, symbol, combined mark,
company name).
ʹlp:claimEntitlementʹ indicates the applicantʹs entitlement to the claim (i.e. owner or licensee). ʹlp:claimRegDateʹ contains the date of registration of the claim.
ʹlp:claimExDateʹ contains the date of expiration of the claim.
ʹlp:claimCountryʹ indicates the country in which the claim is valid.
ʹlp:claimRegionʹ indicates the name of a city, state, province or other geographic region in which the claim is valid. This may be a two-character code from WIPO standard ST.3.

------------------------
4.3.3 command extensions

------------------------
4.3.3.1 EPP Query Commands

ʹinfoʹ command is the only extended query command.

In order to indicate that the query is meant for an application object, an ʹlp:infoʹ element is sent along with the regular ʹinfoʹ domain command.

The ʹlp:infoʹ element contains the following child elements :
ʹlp:applicationIDʹ, the application identifier for which the client wishes to query, and ʹlp:phaseʹ (optional), the phase the application is associated with.
If the query was successful, the server replies with an ʹlp:infDataʹ element along with the regular EPP ʹresDataʹ. The ʹlp:infData contains the following child elements:
* ʹlp:applicationIDʹ the application identifier of the returned application.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.
* ʹlp:statusʹ (optional) status of the application.
* ʹlp:claimʹ (optional) one or more ʹlp:claimʹ elements.
If present, the ʹlp:claimʹ elements may contain the child elements as described above in the claim object description.

------------------------
4.3.3.2 EPP Transform Commands

There are three extended EPP transform commands : ʹcreateʹ, ʹdeleteʹ and ʹrenewʹ

------------------------
4.3.3.2.1 EPP ʹcreateʹ Command

The EPP ʹcreateʹ command is used to create an application. Additional information is required to submit a domain name application during a launch phase :
* ʹlp:phaseʹ (optional), the phase the application should be associated with
* ʹlp:claimʹ (optional) elements to substantiate the prior rights of the applicant.

When such a ʹcreateʹ command has been processed successfully, the EPP ʹextensionʹ element in the response contains a child ʹlp:creDataʹ element that identifies the registry launchphase namespace and the location of the registry launchphase schema. The ʹlp:creDataʹ element contains a child ʹlp:applicationIDʹ element, which informs the registrar about the application ID the server has assigned.

------------------------
4.3.3.2.2 EPP ʹupdateʹ Command

This extension defines additional elements to extend the EPP ʹupdateʹ command to be used in conjunction with the domain name mapping.
Registry policies permitting, clients may update an application object by submitting an EPP ʹupdateʹ command along with an ʹlp:updateʹ element to indicate the application object to be updated.
The ʹlp:updateʹ element contains the following child elements:
* ʹlp:applicationIDʹ the application identifier for which the client wishes to update.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.

------------------------
4.3.3.2.3 EPP ʹdeleteʹ Command

Registry policies permitting, clients may withdraw an application by submitting an EPP ʹdeleteʹ command along with an ʹlp:deleteʹ element to indicate the application object to be deleted. The ʹlp:deleteʹ element contains the following child elements:
* ʹlp:applicationIDʹ the application identifier for which the client wishes to delete.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.


------------------------
5 - Resources

Four categories of profiles are needed to run the Registry’s Technical Operations : Registry Operations Specialists (I), Registry Systems Administrators (II), Registry Software Developer (III) and Registry Expert Engineers (IV). These categories, skill set and global availability of resources have been detailed in Question 31 (Technical Overview of Proposed Registry) including specific resources set and organisation to provide 24⁄7 coverage and maintenance capacity.
Specific workload for EPP management is detailed below.

------------------------
5.1 - Initial implementation

The set up is operated on the pre-installed virtualization infrastructure. It implies actions by system, database and network administrators to create the virtual servers and install the applicative packages.

Then, developers, assisted by a senior staff member expert in internet technologies and RFCs apply proper configuration for the given TLD. Compliance is strictly tested.

The initial implementation effort is estimated as follows :

Database Administrator 0.03 man.day
Network Administrator 0.03 man.day
System Administrator 0.03 man.day
Software Developer 0.10 man.day
Software Engineer 0.20 man.day

------------------------
5.2 - On-going maintenance

On-going maintenance on the SRS includes integration of new policy rules, evolution of technology, bug fixing, infrastructure evolution, failover testing.

Although all the defined technical profiles are needed for such on-going maintenance operations, on a regular basis, it is mainly a workload handled by monitoring and development teams for alert management, new functional developments and RFC compliance checks, respectively.

The on-going maintenance effort per year is estimated as follows, on a yearly basis :

Operations Specialist 0.20 man.day
System Administrator 0.10 man.day
Software Developer 0.15 man.day
Software Engineer 0.10 man.day

26. Whois

Table of Contents

1 - General description
2 - Data access
2.1 Typology of accessible data
2.2 Profiles for data access control
3 - RDDS architecture
4 - RDDS infrastructure
5 - Rate limitation
6 - Reverse lookups
7 - Interconnectivity and synchronization with other systems
8 - Performance and scalability
9 - ICANN Bulk access compliance
10 - RFC compliance
11 - Resources
11.1 - Initial implementation
11.2 - On-going maintenance


------------------------
1 - General description

Registration Data Directory Service (RDDS) is one of the five vital functions of the Registry.
It is in direct connection with the database of the Shared Registration System and offers access to the public administrative and technical data of the registry.
The registry back-end solution implements data access through various interfaces that will be described below as well as their data access policies.

The main focus will be made on Whois on port 43 following RFC 3912 which is the main point of access.
The web Whois offers similar functionalities, is based on the same architecture and will be presented through screenshots.

The following description will provide full and detailed description of the architecture of the RDDS both from an application and from an infrastructure point of view.
This architecture is the same as the one used in production by AFNIC for .FR zone and has been fully functional for the last 15 years, with the ability to meet stringent SLAs as well as to scale from the management of a few thousands domain names in operations to over 2 million in late 2011.


------------------------
2 - Data access

When considering the data access services, we must address :
* the typology of accessible data
* access control : who can access what kind of data
* performance : guarantee of availability and performance for requesting data

Potential limitations to the systems will also be described.
To be able to maintain a good access to everybody (registrar, holders, outside world), our back-end solution provides multiple access with consistent role and access policies.

------------------------
2.1 Typology of accessible data

Data that can be accessed through the RDDS are mainly :
* contact data : holder, administrative, technical, billing
* domain data : domain name, status
* host data : name servers, IP addresses
* ephemeris : creation, expiration dates
* registrar data

These data are all described in the RFCs and fully compliant to the mapping of RFCs 5730 to 5734 and an example of standard port 43 output is given at the end of the present answer.

------------------------
2.2 Profiles for data access control

= Whois for registrars =

The main registrar access tool is our RDDS service accessible both on port 43 following specifications of RFC 3912 and through web access.
Both web and port 43 RDDS offer natively compliance with privacy law with a “restricted disclosure” flag if needed by the TLD. This option is activated through Extensible Provisioning Protocol (EPP) standard ʹdiscloseʹ parameters while creating or updating a contact and automatically understood by the whois server to anonymize the data.
This service is accessible both in IPv4 and IPv6.
RDDS access for registrar is rate limited to ensure performance. (see performance)

= Public whois =

RDDS access is also available on port 43 to everybody through a rate limited access to ensure performance. (see performance)

= Legal requirements =

AFNIC back end solution implements by default French privacy laws with opt-out holder personal data privacy.
This option can be deactivated if necessary to be compliant with the policy of the TLD.


------------------------
3 - RDDS architecture

= RDDS architecture =

RDDS is running on two load balanced front virtual servers directly connected to two databases : the production database for data access, and a rate-limiting service database which applies rate-limiting policies and store IP involved. This server implements token bucket algorithm to flatten traffic on the server.

The two front servers are load balanced using classical round robin implementation.

The network infrastructure is the same as described in the global architecture (referred to below) and no specific dedicated switch or router is to be considered as the rate limiting tool is an applicative one. A global description of the network infrastructure (switch and routers involved) can be found in answers to Question 32 (Architecture).

[see attached diagram Q26_3_RDDS_architecture_diagram.pdf]
Diagram : RDDS architecture diagram
Description : This diagram shows global interaction between Internet, DMZ and private network zones. Topology of network and servers is illustrated including dedicated IP address scheme and network flows.

= RDDS logical diagram =

Our robust infrastructure shows dual Internet Service Provider (ISP) connectivity both in Ipv4 and Ipv6 (Jaguar and RENATER), redundant firewall and switching infrastructure. This part of the architecture is mutualized for all TLDs hosted.

The networking architecture dedicates LAN for administration, backup and production.

Servers are hosted on different network zones : database for database, private for servers not visible on the internet and public for external servers visible on the DMZ. Dedicated zones are also set up for monitoring servers, administration servers or desktop and backup servers.
RDDS servers are directly on the public zone.
Each server is load balanced and the service is not impacted by the loss of one server, the capacity of each server being sized to be able to host the whole traffic.

Servers hosting the .SNCF TLD are shared with up to an estimated number of 20 TLDs of comparable scale and use case.

= RDDS physical diagram =

The IP scheme used is the following :

2001:67c:2218:1::4:0⁄64 for IPv6 Internet homing
192.134.4.0⁄24 for Ipv4 Internet homing

Production LAN

192.134.4.0⁄24 for public network IP range
10.1.50.0⁄24, 10.1.30.0⁄24 for private network IP ranges distributed on the zones described above.

Backup LAN

172.x.y.0⁄24 : x is a different on each network zone. y is fixed to the value of the associated production LAN in the same zone (for example Private zone production LAN being 10.1.”50”.0⁄24, Private zone backup LAN is 172.16.”50”.0⁄24)

Administration LAN

172.z.y.0⁄24 : z is the value of x+1, x being the digit chosen for the corresponding Backup LAN in the same zone. y is fixed to the value of the associated production LAN in the same zone (for example Private zone production LAN being 10.1.”50”.0⁄24, Private zone administration LAN is 172.17.”50”.0⁄24)

Hot standby of the production database is automatically taken into account by the RDDS Oracle Transparent Network Substrate configuration. Therefore if the database are migrated in hot standby due to failure of part of the system, the Registration Data Directory Services (RDDS) access is automatically swapped to the new base.


------------------------
4 - RDDS infrastructure

In the following description “server” will refer to either a physical or a virtual server.
Due to very fast growth of performance in storage and processors technologies, the infrastructure described below could be replaced by more powerful one available at the time of the set up for the same cost.

At the applicative and system level, AFNIC’s SRS systems are shared with up to an estimated number of 20 TLDs of comparable scale and use case.

AFNIC has invested in very efficient VMWare Vsphere virtualization infrastructure. It provides a flexible approach to recovery both through quick activation of a new fresh server in case of local failure (cold standby) and through global failover to a mirrored infrastructure on another site.
This comes in addition to natural redundancy provided by the load balanced servers.

The RDDS is therefore hosted on virtualized infrastructure on the public zone (Demilitarized Zone - MZ) to the exception of the database, which presents very high rate of I⁄O (Input⁄Output), and is hosted on a dedicated physical infrastructure on the private zone.

The rate limiting database is hosted on one physical dedicated physical server. This server represents no failure point as a failure of the rate limiting system doesn’t affect the service (a standard uniform limitation is then applied instead of intelligent rate limiting).
The main database is the production database also used by the SRS and other registry vital functions and is described more in detail in Question 33 (Database Capabilities).

Databases are based on Oracle technologies. The main database is replicated logically on two sites. Full local recovery processes are in place in case of loss of integrity through the Oracle redolog functions which provides full recovery by replay of historized logged requests.

The whole RDDS service is located in the primary Tier 3 datacenter used by AFNIC in production, the
secondary datacenter serves as failover capacity. Continuity mechanisms at a datacenter level are described in Questions 34 (Geographic Diversity), 39 (Registry Continuity) and 41 (Failover testing).

The detailed list of infrastructures involved can be described as follows :

This infrastructure is designed to host up to an estimated number of 20 TLDs of comparable scale and use case.

= Virtual servers =

RDDS server : 2 servers
* Processor: 1 bi-core CPU
* Main memory: 16 GB of RAM
* Operating system: RedHat RHEL 6
* Disk space: 500 GB

= Data storage : see Question 33 (Database Capabilities) =

= Physical server =

Rate limiting database : 1 server
* Processor: 1 bi-core CPU
* Main memory: 8 GB of RAM
* Operating system: RedHat RHEL 6
* Disk space: 500 GB

Back up servers, backup libraries, Web whois server : mutualized with the global registry service provider infrastructure

= Additionnal infrastructure =

Failover, sandbox, preproduction infrastructure : 3 server
* 1 bi-core CPU, 16 GB of RAM, RedHat RHEL 6, 500 GB

------------------------
5 - Rate limitation

To ensure resiliency of the RDDS a rate limitation mechanism is in place.
RDDS is largely used by various public users and registrars, some of them for domain name drop catching. Potentiality of heavy load on this service is very high.
Therefore a rate limitation is applied with threshold calculated from the level of activity expected in order not to penalize normal use of the service. A double level mechanism enables different threshold for identified IP (white list) from registrar and for the public access.

Rate limitation is directly implemented on the front end server.

Access is rate limited through token-bucket algorithms with rate-limiting IP data stored on a dedicated database.
Penalties are applied as follow :
* any IP : 7,200 request ⁄ 24 hour ⁄ IP.
* white listed IP for registrars : 86,400 requests⁄ 24 hour ⁄IP.


------------------------
6 - Reverse lookups

The web RDDS access offers advanced searchability capacities.
The following functions are available :

= Direct queries =

* Partial match query on domain name, administrative, technical, and billing contact name and address, registrant name and address, registrar name including all the sub-fields described in EPP (e.g., street, city, state or province, etc.).
* Exact match query on registrar id, name server name, and name server’s IP glue records
The result of direct queries is the object queried (contact, domain, ...)


= Reverse queries =

* Partial match query on domain name, administrative, technical, and billing contact name and address, registrant name and address, registrar name including all the sub-fields described in EPP (e.g., street, city, state or province, etc.).
* Exact match query on registrar id, name server name, and name server’s IP glue records including IPv6 queries.
The result of reverse queries is the list of objects of a given type linked with the result object (list of domains with a given contact result, or name server result,...)

This powerful tool is limited in access :
* Captcha system avoids scripting of the interface.
* Direct queries are open to every user but the number of result objects is limited to 1,000 answers for 1 query.
* Reverse queries can only be done by registrars on the extranet interface, and the number of result objects is limited to 10,000 answers for 1 query. The interface cannot be used more than 100 times a day.


------------------------
7 - Interconnectivity and synchronization with other systems

= SRS =

Data updated by the SRS are immediately visible in the RDDS with no further synchronisation needed. Rate limitation is applied both on SRS and RDDS service to avoid any load on the database. SRS and RDDS are partly in the same network zone, both RDDS servers and EPP SSL reverse proxies being in the public network zone (DMZ).

= Main database =

Hot standby of the production database is automatically taken into account by the RDDS Oracle Transparent Network Substrate configuration. Therefore if database are migrated in hot standby due to failure of part of the system, the RDDS service is automatically swapped to the new architecture.

= Rate limiting database =

No standby is implemented on the rate-limiting database. In case of failure, a standard global limitation is applied while, replacement of the database is operated.

= Monitoring =

Monitoring is operated through probes and agents scanning systems with a 5 minutes period. The monitoring system gets snmp data from all servers described in the RDDS architecture and also from dedicated Oracle monitoring agent for the database.
Hot standby is not implemented on monitoring agents.

------------------------
8 - Performance and scalability

The Registry’s RDDS offers high level production SLAs and derives from the branch of systems that have evolved over the last 12 years to successfully operate a set of french ccTLDs.

The Registry’s RDDS is used to publish .fr, .re, .yt, .pm, .tf, .wf TLDs information. It is used by more than 800 registrars in parallel managing more than 2 millions domain names and by a large user community.

AFNIC’s RDDS is designed to meet ICANN’s Service-level requirements as specified in Specification 10 (SLA Matrix) attached to the Registry Agreement.

As described in Question 31 (Technical Overview) in relation to each of the phases of the TLD’s operations, the following transaction loads are expected on the WHOIS servers : 50 queries⁄hour on average for both launch phase and on going operations.

AFNIC’s WHOIS systems can serve up to 10,000 requests⁄min on load balanced service to be compatible with the launch and growth scenario described in Question 31 (Technical Overview).

The targeted TLD objective being around 4,000 domain names with a provision for 50 queries⁄hour on average, this ensures that enough capacity is available to handle the launching period, as well as demand peaks and unexpected overhead.

Capacity planning indicators are set up to anticipate exceptional growth of the TLD.
Technologies used enables quick upgrade on all fields :
* Servers : virtual resizing to add CPUs or disk space if resource is available on the production ESX servers. If not, 2 spare additional ESX servers can be brought live if additional performance is needed.
* Servers (alternate) : additional servers can be added and taken into account immediately through dns round robin algorithm.
* Database : database capacity has been greatly oversized to avoid need of replacement of this physical powerful server. Precise capacity planning will ensure that sufficient delay will be available to acquire new server if needed. A threshold of 40% of CPU use or total storage capacity triggers alert for acquisition.


------------------------
9 - ICANN Bulk access compliance

The Registry Operator will provide both data escrow and ICANN bulk access in a same process.
Data escrow generates data on a daily basis. One file per week is kept for ICANN access to bulk data.


------------------------
10 - RFC compliance

The system has been launched compliant with RFCs. Mechanisms are in place to ensure that on going maintenance and new functional delivery stay compliant with RFCs.

= Delivery process =

The RDDS evolutions are developed on the development environment.
The development process implies strict coding rules and use of shared best practices. Pair programming is standard practice. Unit test are developed prior to function development to ensure resiliency of the produced code.

Delivery process take place in four steps :
* 1st step : RDDS validation and RFC compliance is checked through automated tools. A 100% compliance signal must be received to be able to proceed to second step.
* 2nd step : delivery to the pre-production environment. The development is delivered on the preproduction environment. This environment is available for internal testing team.
* 3rd step : delivery to the sandbox environment. This sandbox environment is opened for registrar where they have two accounts to validate their clients before production activation.
* 4th step : the new release is delivered in production.

= Format validation =

RDDS rfc compliance is reached through a specific RDDS checker which is use for non-regression test before each new release.

= Cross checking =

Whois cross checking partnership is established with .at Registry operator to validate in sandbox environment prior to delivery in production through mutual agreement.

= Whois Output =

* Output of a whois query is 100% similar to the whois query example available in RFC 3912.

------------------------
11 - Resources

Four categories of profiles are needed to run the Registry’s Technical Operations : Registry Operations Specialists (I), Registry Systems Administrators (II), Registry Software Developer (III) and Registry Expert Engineers (IV). These categories, skillset and global availability of resources have been detailed in Question 31 (Technical Overview of Proposed Registry) including specific resources set and organisation to provide 24⁄7 coverage and maintenance capacity.
Specific workload for RDDS management is detailed below.


------------------------
11.1 - Initial implementation

The initial implementation effort is estimated as follows :

Database Administrator 0.03 man.day
Network Administrator 0.03 man.day
System Administrator 0.03 man.day
Software Developer 0.10 man.day
Software Engineer 0.05 man.day

------------------------
11.2 - On-going maintenance

On-going maintenance on the RDDS module includes mainly integration of new policy rules, privacy law evolutions, evolution of contracts, infrastructure evolution, failover testing.

Although all the defined technical profiles are needed for such on-going maintenance operations, on a regular basis, it is mainly a workload handled by monitoring and development teams for alert management and new functional developments, respectively.

The on-going maintenance effort per year is estimated as follows, on a yearly basis :

Operations Specialist 0.15 man.day
System Administrator 0.05 man.day
Software Developer 0.05 man.day
Software Engineer 0.10 man.day

27. Registration Life Cycle

Table of Contents

1 - Global description
2 - Data associated with a domain name
2.1 - Technical data
2.2 - Administrative data
3 - Full domain name lifecycle overview
4 - Basic create⁄update⁄delete life cycle
4.1 - create
4.2 - update
4.2.1 - technical update
4.2.2 - administrative update
4.2.3 - context update
4.3 - delete⁄restore
5 - Transfer
6 - Renewal and auto-renewal
7 - Grace period and refund
8 - Resources allocated
8.1 - Initial implementation
8.2 - On-going maintenance


------------------------
1 - Global description

Domain names represents the core technical part of the Domain Name System. The lifecycle of a domain name can have both technical impacts, when it relates to technical data associated with the domain name, and administrative impact when related to the registrant of the domain name.

The following diagrams and descriptions will bring detailed answers to the question of the lifecycle of the domain name in regards to both these aspects

------------------------
2 - Data associated with a domain name

To clearly understand the lifecycle of the domain name, we must first give an exhaustive description of the data involved in the various operations to be made.

------------------------
2.1 - Technical data

A domain name is a technical label used for Domain name resolution. To be effective, it is associated with nameservers -server hosting the configuration of the domain name -, IPv4 and IPv6 addresses - to identify on the network servers independently of the DNS, DNSsec signature information - delegation signer and cryptographic algorithm used-.
Less directly related to the technical basic configuration are :
* = clientHold = label : relates to the DNS or not DNS-publication status of the domain name.
* = auth_info = : a protection code linked with the domain and used by the owner to unlock some operations
* = client*Prohibited = : a list of status activated by the registrar to lock the domain name and prevent some operations
* = server*Prohibited = : a list of status activated by the registry service provider to lock the domain name and prevent some operations

------------------------
2.2 - Administrative data

A domain name has to be managed by his owner. Therefore it comes associated with a list of operational and administrative contacts that can be used to get in relation with the domain name owner or technical staff. The most important are administrative contact, technical contact, billing contact, and of course registrant contact. The last contact object is the registrar object which shows which registrar is in charge of domain name operations at the registry level.

Both these administrative and technical data are modified and used in the lifecycle and we will now describe this in detail.


------------------------
3 - Full domain name lifecycle overview

We have chosen to illustrate the registration lifecycle through a state diagram
This state diagram is joined as a separate file.

[see attached diagram Q27_3_global_lifecycle.pdf]
Diagram : Global Lifecycle
Description : Considering the wide range of the states and transition, the choice has been made to present a linear scenario going through all available operations. In this scenario, impact on registrar objects, registrant objects, domain objects, host objects are described at each step. Also statuses and forbidden operations at each step are indicated.
The following domain states have been introduced to describe the lifecycle major steps :
* registered : the domain name is registered, published in the Registration Data Directory Services (RDDS) but not in the DNS (clientHold label is set or there is no host information)
* active : the domain name is registered, published in the RDDS and in the DNS
redemption : the domain name is registered, published in the RDDS but not in the DNS. It will be - deleted if no action is taken by the registrar.
* locked : specific operations as transfer or delete have been forbidden by the registrar.
Impact on expiry dates has also been indicated though adequate formulas.

All aspects of the registration lifecycle are covered by standard Extensible Provisioning Protocol (EPP) RFCs and the EPP implementation is described in Question 25 (EPP).


------------------------
4 - Basic create⁄update⁄delete life cycle

The basic life cycle is described below without explanation of add grace period. The behavior of add grace period is described in chapter 6.

------------------------
4.1 - create

A domain name is created through a standard EPP domain:create command.
Administrative data linked with the creation are registrant contact, admin contact and technical contact, period before renewal.
Technical data linked with the creation are nameservers host objects, IP address for glue records, auth_info code.
The state of the domain name is REGISTERED if no host objects have been filled.
The state of the domain name is ACTIVE if host objects have been filled.
The state of the domain name can exceptionally be PENDING during the operation if a technical issue makes it asynchronous.
Otherwise this operation is real time and there is no delay elements to be considered.

Elements needed to create a domain are contacts (mandatory), host objects (optional) and auth_code (mandatory).
It can then be managed through domain:update commands.

------------------------
4.2 - update

domain:update commands enables a wide range of fields updates

------------------------
4.2.1 - technical update

Part of the fields of the update enables to update technical configuration. It enables nameserver, IP address, and dnssec options management. It is also used to remove a technical configuration..

The state of the domain name is REGISTERED if no host objects have been filled or have been removed.
The state of the domain name is ACTIVE if host objects have been filled.
The state of the domain name can exceptionally be PENDING during the operation if a technical issue makes it asynchronous.

------------------------
4.2.2 - administrative update

It is used to freely modify the various contacts linked with the domain name : administrative, technical, billing, and registrant contact.
The state of the domain name is not modified if only these fields are used.
The state of the domain name can exceptionally be PENDING during the operation if a technical issue makes it asynchronous.

------------------------
4.2.3 - context update

It is used by the client to modify status of the domain name and⁄or to modify the auth-info code linked with the domain name.
The status that can be changed are the following : clientHold, clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited, clientRenewProhibited.
The clientHold flag enables to remove the domain name from publication temporarily without deleting its technical configuration.
The other client*Prohibited statuses prevent the corresponding operation to be used.
The state of the domain name is REGISTERED if status is updated to clientHOLD.
The state of the domain name is LOCKED if status is updated to clientTransferProhibited.
The state of the domain name can exceptionally be PENDING during the operation if a technical issue makes it asynchronous.

------------------------
4.3 - delete⁄restore

Deletion can be used only by the registrar in charge of the domain name. It brings the domain name in Redemption grace period for a period of 30 days. It can be restored at any time during this period without any changes to the data. Deletion remove the domain name from the DNS publication service.
The state of the domain name is DELETED during redemption period.
The redemption period lasts 30 days. The domain is destroyed at the end of this period and a notification is sent.


------------------------
5 - Transfer

The transfer is described below without explanation of transfer grace period. The behavior of transfer grace period is described in chapter 6.

A transfer can be initiated only by an incoming registrar and using the auth_info that the owner has given him. This standard mechanism acts as a security and associates the triggering of transfer to the acceptance of the owner of the domain.
The transfer operation can be triggered only if the domain is not protected by a clientTransferProhibited lock.

[see attached diagram Q27_5_transfer_lifecycle.pdf]
Diagram : Transfer lifecycle
Description : Transfer operation includes various steps with impact on both outgoing and incoming registrars.

The outgoing registrar receive a transfer notification and can technically accept or reject the registrar change. Rejection can only be done in specific cases described in ICANN consensus policies.
If the outgoing registrar accepts the transfer, the operation is accepted immediately.
If the outgoing registrar does not validate the transfer, the operation is automatically accepted after 5 days.
If the outgoing registrar rejects the transfer, the operation is automatically cancelled and both registrars are notified of the rejection.
When the transfer succeeds, both registrars are notified through their EPP notification queue.

A reverse transfer can be asked by the losing registrar. The documents and cases where this cancellation of the transfer can be asked follow ICANN consensus policies on transfers. In case of disputes, the ICANN TDRP (Registrar Transfer Dispute Resolution Policy) is followed.

The state of the domain name is PENDING during the operation.


------------------------
6 - Renewal and auto-renewal

Domain:renew command is used by the registrar to increase the period of registration. If a domain name is registered for less than 10 years it can be renewed for a period up to 10 years at any time. The expiry date is updated.
The domain:renew command can be sent at any phase of the lifecycle (exception of add grace period is described in next chapter).

The registry lifecycle works with auto-renewal mechanisms. If a registrar do not renew or delete the name when it reaches the expiration date, a one year auto-renew period is added. As for other commands, a grace period is linked with this action (see chapter 6)

[see attached diagram Q27_6_grace_period_renew_autorenew_lifecycle.pdf]
Diagram : Grace Period renew⁄autorenew lifecycle
Description : This renew⁄autorenew lifecycle sum up impact of operations on domain name availability and statuses.


------------------------
7 - Grace period and refund

= Grace period =

The Grace Period mechanism refers to a specified period following an operation or change of status in which the operation may be reversed and a credit may be issued to the Registrar.

= Redemption Grace Period =

The Redemption Grace Period has been described in the delete⁄restore chapter.
During this period, domain name is still registered and can be reactivated through domain:restore command. No specific refund is linked with this period.

= Create - Add Grace Period (AGP) =

The implemented AGP is a five-day period following the domain:create command of a domain name.
The Registrar may delete the domain name at any time during this period and receive a full credit for the registration fee from the Operator. Once a domain name is deleted by the registry at this stage, it is immediately available for registration by any registrant through any Registrar.

= Auto-renew Grace Period =

The auto-renew add grace period is implemented. If during this 45 days period the domain is deleted by the incoming registrar, the ʹdomain:renewʹ command is refunded.

= Renew Grace Period =

The renew grace period is implemented. If during the 5 days period following explicit renew bye the registrar, the domain name is deleted, the renew is then refunded.

= Transfer Grace Period =

The transfer grace period is implemented. If during the 5 days period following a transfer the domain is deleted, the transfer is then refunded.

= AGP Limits Policy =

If too many deletions take place during the AGP from a given registrars, a financial penalty is applied.
The Add Grace Period Limits Policy allows a registrarʹs account to be debited each month for all AGP deletions that exceed the greater of either:
* 50 domain names, or
* 10% of net new adds for the previous month


------------------------
8 - Resources allocated

Four categories of profiles are needed to run the Registry’s Technical Operations : Registry Operations Specialists (I), Registry Systems Administrators (II), Registry Software Developer (III) and Registry Expert Engineers (IV). These categories, skillset and global availability of resources have been detailed in Question 31 (Technical Overview of Proposed Registry). Specific workload for this question is detailed below.

------------------------
8.1 - Initial implementation

The set up of a precise lifecycle implies actions by developers, assisted by a senior staff member expert in internet technologies and RFCs to apply proper configuration for the given TLD. Compliance is strictly tested.

The initial implementation effort is estimated as follows :

Software Developer 0.20 man.day
Software Engineer 0.20 man.day

------------------------
8.2 - On-going maintenance

On-going maintenance on the lifecycle includes mainly integration of new policy rules.
The on-going maintenance effort per year is estimated as follows, on a yearly basis :

Software Developer 0.20 man.day
Software Engineer 0.20 man.day

28. Abuse Prevention and Mitigation

Abusive registration and other activities that have a negative impact on internet users
1. Overview
2. Whois Abuse Prevention Policies
2.1 Whois Accuracy
2.1.1 Syntax and semantic registration constraints
2.1.2 Verification tools
2.1.3 Whois Data Reminder Policy (WDRP)
2.2 Protection against unfair use of Whois service
2.2.1 Protection against Data Mining
2.2.1.1 Captcha
2.2.1.2 Rate-limiting
2.2.2 Prevention of Unauthorized data modification
3. Prevention from other abusive conducts
3.1 DNSSEC (cache poisoning)
3.2 Domain name Sniping (grabbing)
3.3 Domain name tasting
4. Disposal of Orphan Glue Records
5. Single Abuse Point of Contact
6. Policies for handling complaints regarding abuse
6.1 Abuse case response
6.2 Rapid Takedown Policy for Cases of General Malicious Activity
6.3 Rapid Takedown Policy for Cases of Phishing
6.4 Trademark abuse
7. Resourcing Plans

8. SNCF’s Draft Registration Policy

1. Overview
The applicant’s objective in answering question 28 is to provide a thorough explanation of its policies and procedures to minimize abuse registration and other activities that have a negative impact on internet users.

Protection of the internet users is a core value of the project and is key to insuring the user experience as described in question 18 (b) iii. By implementing anti-abuse policy the registry will also contribute to protecting the integrity, security and stability of the Domain Name System (DNS).

As stated in response to Question 18, the applicant’s registration policy will address the minimum requirements mandated by ICANN including abuse prevention measures. The applicant intends to operate the .SNCF registry using strict eligibility criteria. This will significantly lower the risk of abuse in the .SNCF registry. The applicant’s draft registration policy is attached to this response.

Definition of abuse
The applicant defines abuse as an action that causes actual and substantial harm, or is a material predicate of such harm, and is illegal, illegitimate, or otherwise contrary to registration policy. Abuse includes, without limitation, the following:
• Content or actions that attempt to defraud members of the public in any way (for example, ʺphishingʺ sites);
• Content that is hateful, defamatory, derogatory or bigoted based on racial, ethnic, political grounds or which otherwise may cause or incite injury, damage or harm of any kind to any person or entity;
• Content that is threatening or invades another personʹs privacy or property rights or is otherwise in breach of any duty owed to a third party;
• Content or actions that infringe the trademark, copyright, patent rights, trade secret or other intellectual property rights, or any other legal rights of BOSCH or any third party;
• Content or actions that violate any applicable local, state, national or international law or regulation;
• Content or actions that promote, are involved in or assist in, the conduct of illegal activity of any kind or promote business opportunities or investments that are not permitted under applicable law;
• Content that advertises or offers for sale any goods or services that are unlawful or in breach of any national or international law or regulation; or
• Content or actions associated with the sale or distribution of prescription medication without a valid prescription;
• Content that depicts minors engaged in any activity of a sexual nature or which may otherwise harm minors;
• Activities that mislead or deceive minors into viewing sexually explicit material;
• Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks;
• Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;
• Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through Domain Name System (DNS) hijacking or poisoning;
• Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. - Examples include, without limitation, computer viruses, worms, keyloggers, and trojan horses;
• Botnet command and control: Services run on a domain namethat are used to control a collection of
• illegally compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks); and
• Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

The .SNCF registry is committed to create and implement policies and procedure that prevent abusive registrations and other activities that have a negative impact on internet users. In line with the industry best practises presented in the Registration Abuse Policies Issues Report (ICANN 2008), the .SNCF registry will offer a wide range of effective safeguards to prevent abusive uses of domain names such as phishing, spamming, and also unlawful or fraudulent actions. The registry operator will regularly update these policies and procedures in order to maximize its readiness to deal with new threats at all levels and new forms of abuse.

Prevention starts at the time of registration, Whois accuracy (see below in 2) is therefore the first and main focus of the .SNCF registry prevention policies. The following answer describes in details the mechanisms in place to maximize Whois accuracy. Others mechanisms (see below in 3) will be implemented and described here, including management of orphan glue records (see below in 4).

In addition to strong preventive measure against various forms of abuse, the .SNCF registry will implement mitigation policies to address actual cases of abuse that may occur. This answer will describe these mitigation measures in detail: single abuse point of contact (see below in 5), complaint handling policy and takedown procedures (see below in 6).

Resources allocated to handle prevention and mitigation will be described at the end of this answer (see below in 7).



2. Whois Abuse Prevention Policies

2.1 Whois Accuracy

RFC3912 specifies the Whois protocol and explain it as follows:

Whois is a TCP-based transaction-oriented query⁄response protocol that is widely used to provide information services to Internet users. While originally used to provide ʺwhite pagesʺ services and information about registered domain names, current deployments cover a much broader range of information services. The protocol delivers its content in a human-readable format.

Information about registered domain names contains very sensitive data. A Registry Operator shall insure the accuracy of the registrant contact information, including administrative, technical and billing contact details. In case of malicious or abusive activity, the Whois contact listed in the Whois database is usually the first and most important source of information. Whois accuracy is therefore a major tool to counter malicious conducts. Whois information may also be required by law-enforcement authorities to identify individuals and organizations responsible for domain names.

The .SNCF registry will make a firm commitment to obtaining true and accurate registration details from each registrant in line with the eligibility criteria in its draft registration policy.

2.1.1 Syntax and semantic registration constraints:

The .SNCF registry is firmly committed to run a “thick-registry” with high quality of data. The first step to accuracy is achieved through syntax and semantic checks.

Standard EPP checks: a first set of tests is implemented in compliance with standards:
- RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, requires contact data to contain a name, a city, a country code and an e-mail address for a syntactically complete EPP request

- RFC 5731, the Extensible Provisioning Protocol (EPP) requires domain object to have at least one associated status value, Date and time attribute values to be represented in Universal Coordinated Time (UTC) using the Gregorian calendar and Validity periods to be measured in years or months with the appropriates units specified using the ʺunitʺ attribute.

- RFC 5732, the Extensible Provisioning Protocol (EPP) requires host object to have at least one associated status value

Additional checks: the following syntax checks are implemented:
- a test to ensure that the domain name has the proper number of labels (which is two for a traditional registry that allows only second level domains to be registered),
- a test to ensure that no hyphens occur in position 3 and 4 of any of the domainʹs U-labels (to protect ʺxn--ʺ and future ACE prefixes),
- a test to disallow hyphens at the beginning or end of the name,
- a test to find ASCII characters which are neither a letter, nor a digit or a hyphen,
- a test to find invalid IDN characters, i.e. characters not contained in any of the support IDN character tables
- a test to validate IP address format using the following scheme:
〈ipv4-addr〉 [1-255](\.[0-255]){3,3}
〈ipv6-addr〉 [a-fA-F0-9:]+(:〈ipv4-addr〉)?
- a test to validate telephone and mail format using the following scheme (with specific tests for fr numbers):
〈num tel〉 \+[1-9][0-9]{0,3}〈sp〉[1-9]([〈sp〉\.-]?[0-9])+
〈num tel fr〉 \+33〈sp〉[1-9]([〈sp〉\.-]?[0-9]){8}
〈e-mail〉 (([^\s\(\)\[\]\.\\〉〈,;:ʺ@]+(\.[^\s\(\)\[\]\.\\〉〈,;:ʺ@]+)*)|(ʺ[^ʺ@\\\r\n]+ʺ))@〈label〉(\.〈label〉)*

Additional checks: the following semantic checks are implemented:
- a test to disallow reserved names if authorisation code is not present
- a test to disallow registry reserved names if authorisation code is not present
- a test to disallow ICANN reserved names
- a test to disallow otherwise reserved or unsuitable names
- a test to ensure that at least one address element is given

2.1.2 Verification tools
This verification procedure is designed to guarantee the reliability and the accuracy of the Whois database. The .SNCF registry will conduct Whois accuracy verification for compliance with criteria concerning the reliability of registrants’ identification: in line with the registration policy, the registry will verify whether the information provided by the registrant when registering the domain name contains inaccurate or false information about the registrantʹs identity.

Those verifications will be carried out on a random basis or following a third-party request.

The registry may ask registrars for additional information or documents, including the production of documentary evidence of compliance with the reliability of the data provided by the registrant if the registry is in possession of documentary evidence indicating inaccurate registrant information (mail returned marked “Not Known at This Address”, bailiff’s report, unidentifiable address, etc.).

A domain name may be blocked under the following circumstances: when a check of the identification data provided by the registrant shows that it is inaccurate or that the registrant is not eligible to register a domain name in the .SNCF registry.

A domain name may also be deleted as a result of such a procedure. The deletion of a domain name can only occur after the registrant has been formally asked to rectify the situation and to modify its registration data to comply with eligibility criteria.

During the redemption period, the domain name can be reactivated with the same configuration. Once deleted, the domain name will re-enter the public domain and can be registered by a new applicant provided the new applicant meets the eligibility criteria.

2.1.3 Whois Data Reminder Policy (WDRP)

In 2003, ICANN adopted the ʺWhois Data Reminder Policyʺ (WDRP, http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm) which obliges ICANN-accredited registrars to send yearly Whois data reminder notices to registrants. These notices contain the Whois data currently on file for the respective domain, as well as instructions for the registrant about ways to correct the data if required. While the .SNCF registry does not intend to replicate this reminder procedure at the registry level, it will require its accredited registrars to comply with the policy.

2.2 Protection against unfair use of Whois service

As stated above, the Whois Service gives access to sensitive data, including contact details of registrants. The .SNCF registry is committed to insure the protection of these data against abusive behaviours. Firstly, the .SNCF registry will implement technical measures to prevent data mining on the Whois, such as automated collection of registrants’ email addresses that may result in spamming. Secondly, the .SNCF registry and its registry backend service provider, AFNIC, will deploy all necessary means to secure access to its database, specifically by implementing procedures in order to prevent Unauthorized Data Modifications. These procedures will reinforce the security of both EPP and Web-based access to Whois data.

2.2.1 Protection against Data Mining

The user of the .SNCF Whois database must commit to using the published data in accordance with relevant laws and regulations. Furthermore, the user must respect the provisions of the French Data Protection Act (Loi informatique et liberté N°78-17 du 6 janvier 1978 modifée). Violation of this act carries criminal penalties.

The user must refrain from any data collection, misuse or any act that could lead to invasion of privacy or damaging the reputation of individuals.
The Registry may at any time filter the access to its Whois services if it suspects malicious use of the Whois service.


2.2.1.1 Completely Automated Public Turing test to tell Computers and Humans Apart (Captcha): users shall pass a Captcha before access is granted to the web based Registration Data Directory Services (RDDS) WHOIS Service.

2.2.1.2 Rate-limiting: The registry has chosen to impose limitation measures on the number of Whois requests that can be made in order to prevent abuse in the use of personal data and to guarantee the quality of the service.
Through a transparent parameter adjustment policy, the registry guarantees quality of service to both occasional users and professionals. The rates and thresholds of this system are described in the answer to question 26.

2.2.1.3 White list: The white list mechanism offers dedicated access for registrars to the port 43 Whois where the incoming traffic must come from two pre-defined IP addresses. This white list access offers higher limit thresholds for registrars.

2.2.2 Prevention of Unauthorized data modification

Data modification is managed through strict authentication and access policies:
- the SSL⁄TLS protocol is used on all interfaces with clients (both EPP and web based SRS),
- a password policy is applied both on the password itself (minimum length, mandatory digits and non-alphanumerical characters), and on the live length of the password,
- the use of an SSL client certificate pre-installed by the registry for EPP access,
- IP authentication limited to two addresses.
The .SNCF registry backend registry services provider, AFNIC, will leverage its experience from operating the French country code TLD (ccTLD), .fr to ensure effective, timely and sufficient Domain Data Access Control.

3 Prevention from other abusive conducts
As indicated above, the applicant will put in place strict eligibility criteria which must be met in order to register domain names in the .SNCF registry. This means that the risk of abuse will be low. The applicant will however put in place the mechanisms below to further mitigate the risk of abuse.

3.1 DNSSEC (cache poisoning):
One of the main authentication issue encountered on the DNS is cache poisoning issue. This directly impacts on data flow at the DNS service level without corrupting or modifying data in the registry database.

Cache poisoning may be addressed by implementing DNSSEC. The registry operator’s registry back-end registry services provider, AFNIC already successfully manages a DNSSEC-enabled zones: on September, 29th 2010, AFNIC, finished adding its 6 ccTLDs key materials (DS records) into the IANA root zone, for domain names ending with .FR. This was achieved after extensive tests with its other TLDs to ensure a smooth well-functioning service. Since then, related DNSSEC operations and monitoring are spread inside AFNIC, alongside all other standard day to day operations, so that DNSSEC is a core service used by default.

3.2 Domain name Sniping (grabbing):
Domain name sniping refers to the practice of trying to re-register potentially interesting domain names immediately after they are deleted.
The .SNCF registry supports the Redemption Grace Period as proposed by ICANN and implements it in full compliance with RFC 3915 (ʺDomain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)ʺ). This greatly reduces the possibility of a domain name being “forgotten” by its registrant. The .SNCF registry’s registration policy should limit the risk of domain name sniping.

3.3 Domain name tasting:
Domain name testing is a practice using the 5-days Add Grace Period (AGP) during which a newly created domain name may be deleted with a refund of the domain fee to check if the domain name is of interest or not. AGP is a policy in place for all generic TLDs and therefore domain name tasting has to be dealt with. . The .SNCF registry’s registration policy should limit the risk of domain name tasting.

In 2008, ICANN introduced the ʺAGP Limits Policyʺ (http:⁄⁄ www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) which addresses these issues resulting from the Add Grace Period. The [-TLD-] TLD, will fully implement this policy by restricting Add Grace Period refunds to registrars according to the limits specified by the policy.

The number of operations concerned are included in ICANN reports and related report columns, as specified in Specification 3 of ICANN Registry Agreement :
• domains deleted within the add grace period (ʺdeleted-domains-graceʺ)
• total number of AGP exemption requests (ʺagp-exemption-requestsʺ)
• total number of AGP exemptions granted (ʺagp-exemptions-grantedʺ)
• total number of names affected by granted AGP exemption request (ʺagp-exempted-domainsʺ)

4. Disposal of Orphan Glue Records
According to the definition found in the ʺSSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebook”, a glue record becomes an ʺorphanʺ when the delegation point Name Server record (the ʺparent NS recordʺ) that references is removed while retaining the glue record itself in the zone. Consequently, the glue record becomes ʺorphanedʺ since it no longer has a parent NS record. In such a situation, registrars and registrants usually lose administrative control over the record, and the recordʹs attribution to a certain registrar may become unclear, which makes it a potential vector for abuse.

The glue record policy in effect for the .SNCF registry avoids this situation entirely by disallowing orphan glue records altogether. This corresponds to policy #3 mentioned in section 4.3 (page 6) of the SSAC document mentioned above. The technical implementation within the Registry and its associated zone generation process ensures this through the following measures:

- Any host object which is a glue record can be created only if the domain name exist and is sponsored by the registrar creating the host,

- Any deletion of a domain name which has subordinate hosts can be done only when these hosts are deleted. If these hosts are used in delegations for other .SNCF domain names, these delegations have to be removed to delete the host objects and then the domain name.

If the sponsoring registrar of the domain name cannot remove these delegations (explicit refusal or inactivity from subordinate hosts registrars), the situation can be resolved by making a direct request to the registry. Upon such a request, the registry will contact the domain name(s) registrars which were used in the delegation the host object(s) and ask them to remove the delegations. Registrars have 10 days to remove these delegations, after which time if there is no removal of delegation, the registry will deactivate the DNS configuration of the domain name(s) concerned. At the end of the procedure, the registry will contact the sponsoring registrar to inform the registrar that the host object(s) and the domain name can be deleted.

5. Single Abuse Point of Contact
To avoid abusive registration practices, the .SNCF registry will provide internet users with a single point of contact on its website to receive reports of any abuses such as phishing, spamming, trademark abuse etc.

This single point of contact will enable a quicker and better management of complaints. Complaints can be lodged by filling out a form through an online web interface on the .SNCF registry web site

A dedicated team will be in charge of handling the complaints in a a timely manner. All requests should be acknowledged and processed within 24 hours. According to the nature of the reported abuse (phishing, spamming, trademark abuse, etc), appropriate action will be taken by the .SNCF registry.

Moreover, Internet users will be given access to all necessary information regarding remedies to abusive online conducts on the registry Single Abuse Point of Contact webpage. The single abuse point of contact webpage will also contain links to other relevant organizations addressing these issues.

6. Policies for handling complaints regarding abuse
6.1 Abuse case response

The registry will process each complaint within 24 hours and will take all the necessary steps to provide a satisfactory answer to the complainants.

Should immediate action need to be taken by competent authorities (e.g. law enforcement authorities), the .SNCF registry is committed to alert such authorities without delay. As the leading French registry, AFNIC the back-end registry services provider, has a proven record of handling such cases and will continue to work closely with relevant authorities. This may involve, but is not limited to, the following cases:
• Court orders,
• Inquiries from law enforcement bodies (e.g, OCLCTIC - The Office central de lutte contre la criminalité liée aux technologies de lʹinformation et de la communication is the French Police unit specialized in cybercrime),
• Anti-phishing groups (e.g, CERTs).

6.2 Normal Takedown Policy for Cases of Normal Malicious Activity
The .SNCF will put in place a detailed policy for managing normal cases of malicious behaviour such as spam prior to the launch of the .SNCF registry.
6.3 Rapid Takedown Policy for serious cases of abuse
The .SNCF registry will put in place a detailed policy for managing serious cases of abuse such as phising or abuse which threatens the technical operations of the Registry or which may have a serious impact on the Internet. These serious cases of abuse will be managed through a rapid process where the domain name may be suspended to mitigate the impact of the abuse and to allow for further investigation.
6.4 Trademark abuse
The registry understands and agrees that it must comply with the different rights protection mechanisms such as the Uniform Domain Name Dispute Resolution Policy (UDRP) and the Uniform Rapid Suspension System (URS) as described in the gTLD Applicant Guidebook (as may be later amended via Consensus Policy) and the Registry Agreement. The policies for addressing these forms of abuse are described in the response to question 29.

7. Resourcing Plans
.SNCF registry has effectively mitigated the risk of abuse in the gTLD and foresees allocating a member of staff to act as the primary points of contact for handling inquiries relating to malicious or abusive conduct in the TLD. The .SNCF registry is committed to ensuring that sufficient resources are made available at all times.

The .SNCF registry’s back-end registry services provider AFNIC, provides the following resources
Initial Implementation: Thanks to the experience and prior investment by its Registry Back-end Service Provider (AFNIC), the .SNCF registry already supports the above mentioned technical abuse prevention and mitigation measures. No additional engineering is required for these, nor are additional development resources needed.

Ongoing maintenance: In support of the Registry Operator’s staff allocated to this function, AFNIC will have specially trained support staff available to assist in the implementation of potential verifications and takedown procedure for the prevention and resolution of potential abuse. Given the scale of the .SNCF registry as well as the restrictive nature of its registration policy, we estimate that this would require no more than 10 man days per year of AFNIC’s anti-abuse support staff.

8.SNCF’s DRAFT REGISTRATION POLICY

1. DOMAIN NAME LICENCES

Upon registration of a Domain Name, the Registrant holds a licence to use the Domain Name for a specified period of time in accordance with the Registry Rules. Domain Names may be registered and renewed for 1, 2, 3, 4, 5, 6, 7, 8, 9 or 10 years.

2. SELECTION OF REGISTRARS

Registrars eligible to register domain names must meet the following non-discriminatory criteria (in compliance with clause 2.9 (a) of the Registry Agreement):
(i) be an accredited ICANN Registrar;
(ii) demonstrate a level of understanding of the Domain Name registration policies of the Registry;
(iii) have experience of managing the Domain Names of major corporations;
(iv) have proven tools for domain name portfolio management;
(v) have business processes to perform automated validation (and any additional human checks as required by the Registry) of the eligibility of the domain name for registration according to the Domain Name policies of SNCF;
(vi) demonstrate a sufficient level of security to protect against unauthorised access to the Domain Name records;
(vii) demonstrate experience and have appropriate resources in managing abuse prevention, mitigation and responses;
(viii) provide multi-language support for the registration of IDNs;
(ix) comply with any re-validation of its Registry-Registrar agreement at such regular intervals as are determined by the Registry or as required by ICANN from time to time;
(x) meet applicable technical requirements of SNCF; and
(xi) comply with all conditions, dependencies, policies and other requirements reasonably imposed by SNCF, including maintenance of suitable systems and applications that are capable of interacting with the Registry system.


3. ELIGIBLE REGISTRANTS

The Registrant must be:
(i) an Affiliate entity of SNCF; or
(ii) an organisation explicitly authorised by SNCF; or
(iii) a natural person explicitly authorised by SNCF.
If the Registrant does not meet one of the above eligibility criteria, there is no entitlement to register a Domain Name under the sncf gTLD. If the Registrant ceases to be eligible at any time in the future, the Registry may cancel or suspend the licence to use the Domain Name immediately.

4. REGISTRY APPROVAL REQUIREMENT

Registration of Domain Names under the sncf gTLD must be approved by SNCF in addition to meeting all requirements under the Registry Rules. SNCF’s approval for a complete and validly submitted application will be authorised by:
(i) a head of appropriate department as nominated by SNCF (“Authorisation Provider”); or
(ii) an authorised person as nominated by SNCF (“Authorised Person”) and notified to the Registrar from time to time.
The Authorisation Provider will notify the Registrar of its decision.

5. REQUIRED CRITERIA FOR DOMAIN NAME REGISTRATION

An application for Domain Name registration must meet all the following criteria:
(i) availability;
a. the Domain Name is not already registered;
b. it is not reserved or blocked by the Registry; or
c. it meets all Registry’s technical requirements.
(ii) technical requirements;
a. a maximum of 63 characters (after its conversion into the ASCII for IDNs);
b. use of characters selected from the list of supported characters as nominated by the Registry; and
c. any additional technical requirements as required by the Registry from time to time.
(iii) the Domain Name must be consistent with the mission and purposes of the gTLD and consistent with the Domain Name registration policy of SNCF, and include but not be limited to:
a. product name;
b. service name;
c. marketing term;
d. geographic identifier; or
e. any relevant name or term as approved by Authorisation Provider or Authorised Person.
(iv) compliance with all requirements under the Registry Rules: the Registrant must comply with all provisions contained in the Registry Rules.


6. OBLIGATION OF REGISTRANTS

The Registrant must enter into an agreement with the Registrar for Domain Name registration under which the Registrant will be bound by the Registry Rules specified through the Registry-Registrar agreement as amended by the Registry from time to time.

The Registrant must also agree to be bound by the minimum requirements in clause 3.7.7 of ICANNʹs Registrar accreditation agreement.

The Registrant must represent and warrant that:
(i) it meets, and will continue to meet, the eligibility criteria at all times and must notify the Registrar if it ceases to meet such criteria;
(ii) the registration, renewal and use of the Domain Name does not violate any third party intellectual property rights, applicable laws or regulation;
(iii) it is entitled to register the Domain Name;
(iv) the registration and use of the Domain Name is made in good faith and for a lawful purpose;
(v) if the use of registered Domain Name is licensed to a third party,
a. the Registrant must have a licencing agreement with the licensee for the use of the Domain Name that is not less onerous than the obligation of the Registrant contained in the Registry Rules; and
b. where there is a breach of any provisions contained in the Registry Rules by the licensee of the Domain Name, Registry may revoke the Domain Name at its sole discretion.
(vi) it owns or otherwise has the right to provide all registration data (including personal information) for each Domain Name registered and provision of such registrant data complies with all applicable data protection laws and regulations; and
(vii) It has appropriate consent and licences to allow for publication of registration data in the WHOIS database.

7. REGISTRANT CONTACT INFORMATION

The Registrant must provide complete and accurate contact information of the Registrant (in accordance with clause 3.7.7.1 of the ICANN’s Registrar accreditation agreement), including but not limited to the following;
(i) if the Registrant is a company or organisation:
a. name of a company or organisation;
b. registered office and principal place of business; and
c. contact details of the Registrant including e-mail address and telephone number;
(ii) if the Registrant is a natural person:
a. full name of the Registrant;
b. address of the Registrant; and
c. contact details of the Registrant including e-mail address and telephone number.

All Registrant contact information must be complete and accurate. Any changes to such Registrant information must be promptly notified to the Registrar, and no later than one (1) month of such change.

8. REVOCATION OF DOMAIN NAMES

The Registrant acknowledges that the Registry may revoke a Domain Name immediately at its sole discretion:
(i) in the event the Registrant breaches any Registry Rules;
(ii) to comply with applicable law, court order, government rule or under any dispute resolution processes;
(iii) where such Domain Name is used for any of the following prohibited activities (Prohibited Activities):
a. spamming;
b. intellectual property and privacy violations;
c. obscene speech or materials;
d. defamatory or abusive language;
e. forging headers, return addresses and internet protocol addresses;
f. illegal or unauthorised access to other computers or networks;
g. distribution of internet viruses, worms, Trojan horses or other destructive activities; and
h. any other illegal or prohibited activities as determined by the Registry.
(iv) in order to protect the integrity and stability of the domain name system and the Registry;
(v) where such Domain Name is placed under reserved names list at any time; and
(vi) where Registrant fails to make payment to the Registrar for registration, renewal or any other relevant services.

9. USE OF SECOND OR THIRD LEVEL IDNS

In addition to meeting all required criteria for registration of domain names above, an application for an IDN Domain Name must:
(i) comply with any additional registration policy on IDNs for each language;
(ii) meet all technical requirement for the applicable IDN;
(iii) comply with the IDN tables used by the Registry as amended from time to time; and
(iv) meet any other additional technical requirements as required by the Registry.

10. USE OF GEOGRAPHIC NAMES

All two-character labels and country and territory names will be initially reserved in accordance with specification 5 of the Registry Agreement.
Upon approval from ICANN and any other guidelines by applicable governments and ICANN’s Governmental Advisory Committee, the Registry may release the two-character labels and country and territory names in accordance with SNCF’s response to Question 22 Geographic Names.

11. RESERVED NAMES

The Registry may place certain names in its reserved list from time to time where:
(i) the Registry believes in its sole discretion that use of such names may pose a risk to the operational stability or integrity of the Registry;
(ii) in accordance with ICANN’s specifications contained in the Registry Agreement, guidelines or recommendations;
(iii) there is a risk of trademark infringement or where the name otherwise may cause confusion taking into consideration the mission and purpose of the gTLD; or
(iv) the Registry in its sole discretion decides certain names to be reserved for any reason.


12. ALLOCATION OF DOMAIN NAME

The Registry will register Domain Names on a first-come, first-served basis in accordance with the Registry Rules. The Registry does not provide pre-registration or reservation of Domain Names.

13. LIMITATION ON REGISTRATION ⁄ DOMAIN NAME LICENCES

There is no restriction on the number of Domain Names any Registrant may hold. The Registrant may further licence the use of the Domain Name to any third parties provided that the Registrant enters into an agreement with such third parties on the terms not less onerous than its obligations under the Registry Rules.

14. PROTECTION OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS

The Registry will implement all rights protection measures as required by ICANN in clause 2.8 of the Registry Agreement, including the use of the Uniform Rapid Suspension (URS) procedure, and Uniform Domain Name Dispute Resolution Policy (UDRP).

15. TERM OF REGISTRATION ⁄ RENEWAL

INITIAL TERM OF REGISTRATION:
A Domain Name can be registered for a period between one (1) to ten (10) years.

RENEWAL OF REGISTRATION:
(i) The term may be extended at any time for a period between one (1) to ten (10) years, provided that the total aggregate term of the Domain Name does not exceed ten (10) years at any time.
(ii) Upon change of sponsorship of the Domain Name from one Registrar to another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars, the term of registration of the registered Domain Name will be extended by one year, provided that the maximum term of registration at any time does not exceed ten (10) years.
(iii) The change of sponsorship of the registration of a Domain Name from one Registrar to another, accordingly to Part B of the ICANN Policy on Transfer of Registrations between Registrars will not result in the extension of the term of registration.

CANCELLATION OF REGISTRATION:
The Registrant may cancel a Domain Name registration at any time by submitting its request in writing with the Registrar.

AUTO-RENEWAL:
Upon expiry of the Domain Name, the Registry will auto-renew the Domain Name for a one year term (1) year term unless the Registrant submits its intention not to renew the Domain Name.

The Registry will implement the business rules for the renewal of Domain Names documented in appendix 7 of the .com Registry Agreement.

16. TRANSFER OF DOMAIN NAMES BETWEEN REGISTRANTS

Any transfer of a Domain Name between Registrants must be approved by the Registry through the Registrar. The legal heirs of the Registrant or purchaser of the Registrant may request the transfer provided that they meet the eligibility criteria for registration under the sncf gTLD. If the Registrant becomes subject to insolvency or any other proceeding, the administrator may request the transfer. The transferee must provide appropriate documentation as required by the Registry to approve such transfer.

17. CHANGE OF REGISTRAR

If the agreement between the Registry and the Registrar is terminated and if the Registrar has not transferred its Domain Name portfolio to another Registrar, the Registry will notify affected Registrants. The Registrants must select a new Registrar within one (1) month following such notice from the Registry. If the Registrant fails to appoint a new Registrar within the timeframe set out above, the Registry may suspend the Domain Name.

If the Registrant wishes to change the Registrar, the Registrant must obtain the auth-info code from the Registrantʹs current Registrar, and request a transfer through the gaining Registrar in compliance with ICANNʹs Inter-Registrar transfer policy.

18. PRIVACY AND DATA PROTECTION

By registering a Domain Name, the registrant authorises the Registry to process personal information and other data required for the operation of the sncf gTLD. The Registry will only use the data for the operation of the Registry including but not limited to its internal use, communication with the Registrant, and provision of WHOIS look-up facility.

The Registry may only transfer the data to third parties:
(i) with the Registrant’s consent;
(ii) in order to comply with laws, regulations or orders by a competent public authority and any Alternative Dispute Resolution (ADR) providers; or
(iii) for a publicly available and searchable WHOIS look-up facility, in accordance with specification 4 of the Registry Agreement.

19. WHOIS

The Registry provides a publicly available and searchable WHOIS look up facility, where information about the Domain Nameʹs status (including creation and expiry dates), and registrant, administrative and the technical contact administering the Domain Name can be found, in accordance with specification 4 of the Registry Agreement.

In order to prevent misuse of the WHOIS look up facility, the Registry requires that any person submitting a WHOIS database query will be required to read and agree to the terms and conditions, which will provide that:
(i) the WHOIS database is provided for information purposes only; and
(ii) the user agrees not to use the WHOIS information to allow or enable the transmission of unsolicited commercial advertising or other communication via email or other methods to the Registrants.

20. PRICING ⁄ PAYMENT

The new gTLD does not charge a separate fee for the Registrar to register domain names, as the gTLD is used only for the specified mission and purpose of SNCF. SNCF shall bear the cost of operating the Registry.

The Registry will provide Registrars with 30 days’ notice of any price change for new registrations, and 180 days advance notice of any price change for renewals in accordance with clause 2.10 of the Registry Agreement.

21. DISPUTE RESOLUTION

The Registrant agrees to be bound by ICANN’s Dispute Resolution Policies in respect of all disputes in connection with the Domain Name.

22. COMPLIANCE WITH CONSENSUS AND TEMPORARY POLICIES

The Registrant agrees to be bound by all applicable consensus and temporary policies as required and mandated by ICANN.

23. DEFINITIONS

Affiliate means in relation to a party any corporation or other business entity controlling, controlled by, or under common control of that party and for the purposes of this definition, a corporation or other business entity shall be deemed to control another corporation or business entity if it owns directly or indirectly:
(i) fifty percent (50%) or more of the voting securities or voting interest in any such corporation or other entity; or
(ii) fifty percent (50%) or more of the interest in the profit or income in the case of a business entity other than a corporation; or
(iii) in the case of a partnership, any other compatible interest equal to at least a fifty percent (50%) share in the general partner.

Domain Name means a domain name registered directly under the sncf gTLD or for which a request or application for registration has been filed with the Registry;

ICANN’s Dispute Policy means the dispute policy currently known as the Uniform Domain Name Dispute Resolution Policy (UDRP) issued and as may be updated from time to time by the Internet Corporation of Assigned Names and Number (ICANN) and the Uniform Rapid Suspension (URS) (see Specification 7 of the Registry Agreement).

Registrar means an ICANN accredited registrar which enters into and is in compliance with the registry-registrar agreement for the TLD, and which provides domain name registration services to Registrants;

Registry means SNCF;

Registry Agreement means the agreement between SNCF and ICANN;

Registry Rules mean:
(i) Registration terms and conditions agreed between the Registry and Registrant for registration of a Domain Name; and
(ii) Registration policies provided and amended by the Registry from time to time.

Registrant means a natural person, company or organisation who holds a Domain Name registration or who has requested or applied for the registration of a Domain Name.

29. Rights Protection Mechanisms

A.	RIGHTS PROTECTION MECHANISMS TO BE IMPLEMENTED BY SNCF

The core purpose of SNCF in operating the .SNCF gTLD domain is to ensure a secure online space for responsible Internet users. In particular, SNCF seeks to establish a trusted and reliable platform for Internet users who wish find information on products and services related to the .SNCF gTLD. Therefore, SNCF has a strong interest in ensuring that all of its policies are implemented and continually enforced. SNCF will implement and adhere to any rights protection mechanisms (RPMs) that may be mandated from time to time by ICANN in line with Specification 7 of the Registry agreement. This includes the Sunrise processes, the Trademark Clearinghouse and Trademark Claims processes, the Uniform Domain Name Dispute Resolution Policy (UDRP), the Uniform Rapid Suspension (URS) and WHOIS processes.

The eligibility criteria for the .SNCF require that each registrant meet the eligibility criteria for the .SNCF as set out in the draft registration policy in Question 28. Prospective registrants must provide all required supporting documentation as requested by the Registry from time to time. Because of these eligibility criteria, the registry does not anticipate that third parties and⁄or trademark owners unrelated to the SNCF will incur costs in relation to the .SNCF gTLD. Furthermore, the identity of registrants will be pre-verified before the registration of any domain names which will lessen the risk of rights infringements.

In the event that third parties perceive that their rights have been infringed, they will have a speedy right of recourse open to them. Given that SNCF has resolved to ensure that abusive use of .SNCF gTLD domain names will not be permitted nor tolerated and that the risk that such abuses inherently create negative publicity and loss of goodwill, SNCF is committed to ensuring that any abuse will be swiftly and effectively addressed, and that systems are in place to mitigate rights protection issues.

Abuses and complaints against domain names in the .SNCF registry will be quickly addressed in the manner set forth in the response to Question 28.

SNCF will go beyond the required rights protection mechanisms defined in Specification 7 of the Registry Agreement by also participating in solutions to monitor potentially malicious conduct over the Internet as outlined below and in the answer to Question 28. This may occur via private contracts with a qualified anti-phishing solutions vendor who will both monitor the TLD zone for abuse and take action to remedy the abuse, and⁄or this may occur via participation in a broader program such as the Abusive Domain Name Resolution Suspension Process (ADNRS) in development by the Anti-Phishing Working Group. Additionally, the measures below will be available at the time of opening up of the registry and will be enforced through contractual means:

- Acceptable use policy: SNCF publicizes its Acceptable use policy which will define abuse, abuse handling processes and the consequences of abuse;
- Rapid Takedown or Suspension Based on Court Orders: SNCF or its approved registrar(s) complies promptly with any order from a court of competent jurisdiction that directs it to take any action on a domain name that is within its technical capabilities as a gTLD registry. These orders may be issued when abusive content, such as child pornography, counterfeit goods, or illegal pharmaceuticals, is associated with the domain name;
- Anti-Abuse Process: SNCF implements an anti-abuse process that is executed based on the type of domain name takedown requested. The anti-abuse process is for malicious exploitation of the DNS infrastructure, such as phishing, botnets, and malware;
- Authentication Procedures: AFNIC, SNCF’s selected backend registry services provider, ensures that data modification is managed through strict authentication and access policies as set out in Question 28;
- DNSSEC Signing Service: Domain Name System Security Extensions (DNSSEC) helps mitigate pharming attacks that use cache poisoning to redirect unsuspecting users to fraudulent websites or addresses. It uses public key cryptography to digitally sign DNS data when it comes into the system and then validate it at its destination. The .SNCF is DNSSEC-enabled as part of AFNIC’s core backend registry services

SNCF will also ensure in all cases that its approved Registrar(s) will adopt appropriate anti-abuse mechanisms, respond to abuse processes and third party rights protection mechanisms and processes, in dealing with any domain name registrations, renewals and use. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible rights protection issues both during the startup phase of the TLD and continually during operations of the TLD. SNCF will ensure that Registrar(s) are contractually bound to provide high quality and responsive management of rights protection queries.

B. REGISTRY OPERATOR PROVIDED RIGHTS PROTECTION MECHANISMS

SNCF acknowledges that it must provide (a) a sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (b) a trademark claims service for at least the first 60 days that second-level registrations are open.

.SNCF has engaged AFNIC to provide certain registry operation services, amongst which are the technical functions required to implement the mechanisms outlined below in respect of sunrise periods, trademark claims periods and the interaction with the Trademark Clearinghouse. The manner in which these elements will be addressed by the various parties is set out in this section. It should be noted that because ICANN, as of the time of this application submission, has not issued final guidance with respect to the Trademark Clearinghouse, .SNCF cannot fully detail the specific implementation of the Trademark Clearinghouse within this application. .SNCF will adhere to all processes and procedures to comply with the ICANN guidance once this guidance is finalized.

Sunrise Services
SNCF acknowledges that all new gTLDs must provide a sunrise registration service for at least 30 days before general registration of domain names.

SNCF confirms that it will implement a sunrise service pre-registration procedure for domain names for 30 days prior to the launch of the general registration of domain names. Prior to the Sunrise Period commencing, SNCF will establish and then notify its registry service provider of the sunrise eligibility requirements for the gTLD. Registrants may register domain names which meet the sunrise eligibility requirements and are registered in the Trademark clearinghouse. The registrant of any registrations of domain names during this period must agree to be subject to the Sunrise Dispute Resolution Policy (SDRP) consistent with Section 6 of the Trademark Clearinghouse Rules as set forth by ICANN. During this period, SNCF, and its approved registrar(s), will verify whether or not a particular domain name is eligible to be registered on an individual case by case basis before adding the necessary command to the Shared Registry Service (SRS) to register the applicable domain name. If there are multiple sunrise applications for an identical domain name, the domain name will be allocated through an auction mechanism.

Trademark Claims Service – Land-rush service
SNCF will provide a trademark claims service for a minimum of sixty (60) days. During this period, SNCF (or its approved registrars on its behalf) shall validate each request for registration of a domain name against trademarks registered in the Trademark Clearinghouse and shall (where applicable) provide notice to each prospective Registrant of a domain name that it is an identical match (as defined in the gTLD Applicant Guidebook) to the mark holder validated in the Trademark Clearinghouse, in the form required by ICANN. The Approved Registrar(s) will then require each registrant to provide the warranties set out in the gTLD Applicant Guidebook before registration of the particular domain name. Those warranties will include receipt and understanding of the Trademark Claims Notice and confirmation that registration and use of said domain name will not infringe on the trademark rights of the mark holders listed. Without receipt of said warranties, SNCF or its approved Registrar(s) will not process the domain name registration.

SNCF and⁄or its approved registrar(s) (as applicable) will be responsible for determining whether a domain name is eligible to be registered and will do so for each domain name before submitting an add command to the gTLD Shared Registry Service to register the applicable domain name.

Following the registration of a domain name, the holders of trademarks that have been previously validated by the Trademark Clearinghouse as an identical match will receive a notice of the domain name registration by SNCF or its approved registrar (as applicable), in the form required by ICANN.

If there are competing applications for an identical domain name, the domain name will be allocated through an auction to be held after the conclusion of the trademark claims⁄land-rush period.

General registration period
Following the expiry of the trademark claims⁄land-rush service, SNCF will provide registrations of domain names from eligible registrants on a first come, first served basis in accordance with the draft registration policy set out in the answer to Question 28.

C. Dispute Resolution

SNCF will comply with the dispute resolution mechanisms required by ICANN including the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP), the Registration Restriction Dispute Resolution Procedure (RRDRP), the Uniform Rapid Suspension (URS), and the Uniform Dispute Resolution Procedure (UDRP). SNCF will implement all determinations and decisions under these mechanisms.

After a domain name is registered, trademark holders can object to the registration through the UDRP or URS. Objections to the operation of the gTLD can be made through the PDDRP. The following descriptions provide implementation details of each post-launch rights protection mechanisms for the .SNCF gTLD:

- UDRP: The UDRP provides a mechanism for complainants to object to domain name registrations. The complainant files its objection with a UDRP provider and the domain name registrant has an opportunity to respond. The UDRP provider makes a decision based on the papers filed. If the complainant is successful, ownership of the domain name registration is transferred to the complainant. If the complainant is not successful, ownership of the domain name remains with the domain name registrant. SNCF and entities operating on its behalf adhere to all decisions rendered by UDRP providers.

- URS: As provided in the Applicant Guidebook and the Registry agreement, all registries are required to implement the URS. Similar to the UDRP, a complainant files its objection with a URS provider. The URS provider conducts an administrative review for compliance with filing requirements. If the complaint passes review, the URS provider notifies the registry operator and locks the domain. A lock means that the registry restricts all changes to the registration data, but the name will continue to resolve. After the domain is locked, the complaint is served to the domain name registrant, who has an opportunity to respond. If the complainant is successful, the registry operator is informed and the domain name is suspended for the balance of the registration period; the domain name will not resolve to the original website, but to an informational web page provided by the URS provider. If the complainant is not successful, the URS is terminated and full control of the domain name registration is returned to the domain name registrant. Similar to the existing UDRP, SNCF and entities operating on its behalf adhere to decisions rendered by the URS providers. The contact details of the .SNCF gTLD abuse point of contact will be provided to all URS providers.

- PDDRP: As provided in the Applicant Guidebook, all registries are required to implement the PDDRP. The PDDRP provides a mechanism for a complainant to object to the registry operator’s manner of operation or use of the gTLD. The complainant files its objection with a PDDRP provider, who performs a threshold review. The registry operator has the opportunity to respond and the provider issues its determination based on the papers filed, although there may be opportunity for further discovery and a hearing. SNCF participates in the PDDRP process as specified in the Applicant Guidebook.

All registrations of domain names will be subject to compliance through contractual means with the above procedures and policies, should disputes occur. SNCF will act as the primary contact for handling inquiries relating to malicious conduct in the gTLD. The abuse point of contact described in the response to Question 28 above will be tasked with also responding to complaints in relation to rights protection.

The primary abuse point of contact will investigate and respond to all complaints and incidents in a timely manner and be empowered to take effective action within well-defined written criteria to guide those actions. Action will be taken in line with what is set out in the answers to Question 28 and 29 and the registration policy for the .SNCF TLD.

D. WHOIS

SNCF will comply with the requirements set out in specification 4 of the registry agreement to ensure readily available information on registrants. SNCF’s mechanisms for ensuring complete and accurate WHOIS data are described in the response to Question 28.

E. Resource planning

Resource planning specific to backend Registry activities
Initial Implementation

Thanks to the experience and prior investment by its Registry Service Provider (AFNIC), the .SNCF already supports the above mentioned functions and appropriate support systems.

One aspect to be considered for resource planning is the registry systemʹs connection to the Trademark Clearinghouse; since the involved API is not fully defined at the time of writing, some software development will have to be done in order to integrate the Clearinghouse into the sunrise workflow, as well as to incorporate it into the designated Trademark Claims Service. It is estimated that a Software Developer will be allocated to work 10 man days on the development of this feature.

Staff are already on hand and will be assigned this work as soon as ICANN releases the relevant technical specifications.

Ongoing maintenance

In support of the SNCF staff allocated to the operation of the rights protections mechanisms mentioned (see below), the Registry Service Provider (AFNIC) will set up a team of highly experienced individuals with a distinct track record in handling dispute and managing TLDs in a manner that very significantly minimizes the risk of problems. These individuals have direct experience from launch management and dispute resolution concerning the different French ccTLDs.

This team will be composed of expert-level staff for respectively handling and advising on issues and individual cases. Their skill set will primarily be consisting of administrative and legal training, as well as domain name policy expertise.

Resource planning specific to other Registry activities and third party registrars
SNCF has effectively mitigated the risk of abuse in the gTLD and foresees dedicating a member of staff to act as the primary point of contact for handling inquiries relating to malicious or abusive conduct in the TLD. SNCF is committed to ensuring that sufficient resources are made available at all times. SNCF may engage its third party registrar(s) and its selected backend registry services provider to perform some or all of the tasks associated with rights protection issues. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible abuse issues both during the startup phase of the TLD and continually during operations of the TLD.

.


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

Table of Contents

1 - Background
2 - Organization of security
2.1 - The place of Security in AFNIC’s processes:
2.2 - Security Coordination
2.3 - Assignment of responsibilities
2.3.1 - Organizational chain of responsibility
2.3.2 - Relations with the authorities and groups of specialists
2.4 - Independent security review
2.5 - Relations with third parties
2.5.1 - Risk Management
2.5.2 - Security of sensitive areas
2.5.3 - Sensitive external sites
2.5.4 - Security assurances for domain name registrants
3 - Registry Asset Management
3.1 - Responsibilities for Registry assets
3.1.1 - Inventory of assets
3.1.2 - Qualification of support assets
3.1.3 - Ownership of assets
3.1.4 - Good and fair use of assets
3.2 - Guidelines for the classification of information
4 - Security related to human resources
4.1 - Roles and Responsibilities
4.2 - Background checks conducted on security personnel
5 - Physical and environmental security
5.1 - Secure areas
5.2 - Hardware security
6 - Operations Management and Telecommunications
6.1 - Procedures and responsibilities related to operations
6.2 - Scheduling and acceptance testing of the system
6.3 - Protection against malicious and mobile code
6.4 - Back-up
6.5 - Security management of network services
6.6 - Monitoring operation of the System
7 - Access Control
7.1 - Business requirements for access control
7.2 - Control of network access
7.3 - Control of access to operating systems
8 - Acquisition, development and maintenance of information systems
8.1 - Cryptographic measures
8.2 - Management of technical vulnerabilities
9 - Managing incidents related to information security
9.1 - Managing improvement and incidents related to information security
10 - IT Disaster Recovery Plan
11 - Integrating audits of the information system


------------------------
1 - Background

The security policy is designed to ensure proper management of the risks that may significantly impact the services provided, the contexts in which they are implemented, and the key personnel involved in operating the Registry. It also defines security level for the scalability ⁄ responsiveness to security incidents, the Registry Data integrity and the confidentiality of personal data of domain name owners.

The Information Security Policy is reviewed at least once a year.


------------------------
2 - Organization of security

------------------------
2.1 - The place of Security in AFNIC’s processes:

AFNIC has set up a Quality Management System (QMS) following the European Framework for QUality Management (EFQM) excellence model. It describes AFNIC’s activities as a series of business processes. Security Process called “ENSURE SECURITY AND BUSINESS CONTINUITY” is one of the cross-business-processes supporting process. It is designed to be compliant with the ISO 27001 norm.
Ensuring security and business continuity mainly consists in defining and controlling how to :
* Supervise the governance of security,
* Apply security measures into the concerned operational fields,
* Manage the risks that could negatively impact the Registries operations.

The implementation of the AFNICʹs ISMS (Information Security Management System) is performed in the framework of the Security process with a view to obtaining ISO 27001 certification by 2014.

------------------------
2.2 - Security Coordination

The overall responsibility for security rests with the CEO. He is assisted in this role by the AFNIC Security Manager (ASM).

Strategic supervision is ensured in a concerted manner by the AFNIC Security Council (ASC) chaired by the AFNIC CEO. The purpose of the ASC is to assist and ensure that the conditions are conducive to attaining the security objectives that fall within the scope of the current strategy.

The ASC further supports the development of security practices at AFNIC through the supporting of operation business functions in implementing security policies, business continuity plans, and staff awareness activities. In carrying out its assignment, the ASC may refer at any time to the Executive Management for advice or a decision on the security of AFNIC and TLD.

------------------------
2.3 - Assignment of responsibilities

------------------------
2.3.1 - Organizational chain of responsibility

The application of security measures to the SRS, DNS, Whois, and other Information Systems is the responsibility of the CTO (head of the Information Systems Division).
The implementation of security measures for staff and premises is the responsibility of the CFO.
The implementation of security measures with respect to legal obligations and registry policies is the responsibility of the Registryʹs Legal Affairs and Policies Director.
The application of security measures relating to damage to the Registryʹs image is the responsibility of the Marketing and Innovation Director.
All the collaborators must be aware of their responsibility concerning the security of resources and information they are accessing, manipulating, publishing.

------------------------
2.3.2 - Relations with the authorities and groups of specialists

AFNIC has an agreement with the French National Agency for the Security of Information Systems (ANSSI). Against this background, the two structures cooperate on security issues that may affect AFNIC services related to its Internet business and risk management in this area.
They cooperate within the framework of two programs on the resilience of the Internet in France :
* Cooperation between the operators of vitals infrastructures in order to improve their capacity to respond to major crises affecting several operators at the same time: the Internet critical services (IP Routing and DNS) are now included in the nomenclature;
* Cooperation to assess the resilience of the French .fr TLD and more generally all the TLDs operated by AFNIC for use by the public.

------------------------
2.4 - Independent security review

Security audits must be conducted by independent organizations twice a year on global and ⁄ or specific issues related to security.

------------------------
2.5 - Relations with third parties

------------------------
2.5.1 - Risk Management

Risk studies are conducted using the EBIOS methodology (Expression of Business needs and Identification of Security Objectives, in French). This method was designed in 1995 by the French National Agency for Information Security. It is currently used to identify the worst-case scenarios that could affect registry activity. That leads Afnic to design and apply mitigation measures to enhance the protection against these worst-case scenarios.

The control of the effectiveness and efficiency of mitigation measures is performed by the AFNIC’s Security Council all along the year.

------------------------
2.5.2 - Security of sensitive areas

All sensitive areas are under control. That means that access must be controlled and could be restricted to authorized personnel only.
Co-contractors may be requested to sign a confidentiality agreement if required by the sensitivity of information and data they need to know and⁄or use. They only have access to critical technical facilities if accompanied, and never work on production systems.

------------------------
2.5.3 - Sensitive external sites

All security must be applied to protect AFNIC’s resources on external sites. That can be made by private zones and access control to them managed by AFNIC itself.

------------------------
2.5.4 - Security assurances for domain name registrants

The Registry guarantees the following for registrants :
* The continuous availability of operations on its portfolio of domain names, in accordance with the SLA on the SRS
* The continuous availability of information related to the domain, on condition that the registrant uses the services provided to carry out the operations in question,
* The confidentiality of the registrantsʹ personal data (except where other special conditions apply related to the policy of the registry)
* The confidentiality of non-public data relating to the domain and ⁄ or its portfolio of domain names,
* The confidentiality of the transactions with the Registryʹs system,
* The integrity of the information related to its domain name,and published in the WHOIS and the DNS.


------------------------
3 - Registry Asset Management

The security of the registryʹs assets is ensured by the staff assigned to the registryʹs production operations and management activities.
Considering the network connectivity provided by third party, AFNIC’s property begins at the service delivery point.

------------------------
3.1 - Responsibilities for Registry assets

------------------------
3.1.1 - Inventory of assets

Assets used in the run of critical services are identified, qualified, and managed under the guidance of the present policy. Assets considered are staff, infrastructure, software, connectivity, data and providers.

------------------------
3.1.2 - Qualification of support assets

The assets contributing to the Services are classified in 3 main categories :
* Computer Systems and Telecommunications : Hardware and Software; Communications Channels; Outsourced Services;
* Organizations : Staff; Corporate departments;
* Physical locations for business : Offices; Hosting Datacenters;

------------------------
3.1.3 - Ownership of assets

Registry data belong to the Registry owner. They are subject to the rules of the contract with ICANN, plus the applicable legal and ⁄ or legislative rules depending on the context in which the registry is implemented

------------------------
3.1.4 - Good and fair use of assets

All the registry operations and services must be used by third party in accordance with the contractual rules defined by the owner and the operator of the TLD.

------------------------
3.2 - Guidelines for the classification of information

The data used or produced in the context of the Registry are classified in the 3 following categories :

= Critical information = : it can⁄must be accessed⁄showed only by accredited persons. Disclosure or alteration may result in significant damage but repairable.

= Reserved information = : Information is limited to persons, entities or authorized partners. Disclosure or alteration may result in significant harm.

= Internal Information = : Information is available to staff of AFNIC and authorized partners. Disclosure or alteration may perturb the normal functioning of the company, without lasting consequence.


------------------------
4 - Security related to human resources

------------------------
4.1 - Roles and Responsibilities

There are 2 categories of staff :

* Technical staff : These personnel have access to resources according to defined rights.
* Administrators in charge of administering production resources. They can access all the production resources and data.
* Technicians in charge of the operation, maintenance and monitoring of the production system. They have limited rights of access to production resources. They can access certain resources on request and when accompanied by an administrator.
* Experts in charge of the design and development of production resources. They only have access to the production resources on request and when accompanied by a technician and ⁄ or an administrator.
* Non-technical staff :
* Administrative staff and managers (excluding production).

------------------------
4.2 - Background checks conducted on security personnel

French law applies to all staff. The contract they sign with their employer contains sufficient provisions in terms of professionalism and ethics for the activity involving the TLD. Same rules are applicable a Data Center level.


------------------------
5 - Physical and environmental security

------------------------
5.1 - Secure areas

AFNIC production sites are secured at the means of access to them. The DATA CENTER sites must meet the standards of industrial and environmental security compatible with the constraints implied by their activity. The layout of the premises must be such that access is restricted only to authorized personnel at entry points selected and controlled by AFNIC.

------------------------
5.2 - Hardware security

The Data centers that host AFNIC services ensure at least Tier 3 levels of resilience.


------------------------
6 - Operations Management and Telecommunications

AFNIC controls the operation of all the resources used to deliver essential services with the exception, of course, of outsourced services such as certain DNS servers.
AFNIC operates dark fiber connections between its sites. The terminals are owned by AFNIC. They are operated by AFNIC personnel.

------------------------
6.1 - Procedures and responsibilities related to operations

Operating procedures are documented and kept up to date on the intranet of the IT team.
Access to the applications, servers and databases must be defined and kept up to date for each staff member.
Access privileges are defined in order to respect the security rules associated with the classification of information.
Operations related to DNSSEC are subject to even more stringent security regulations and require respecting the DPS procedure.

------------------------
6.2 - Scheduling and acceptance testing of the system

The test, pre-production and production phases must be clearly specified. Any production launch must be announced to the registrars at least 2 month before it applies.

------------------------
6.3 - Protection against malicious and mobile code

All the entry points to the production servers are filtered by the firewall, which applies the filtering policy common to all the procedures, whether they involve a human operator or an automated process.

Each development must apply security rules and recommendations on the development of application.
The Web access must be protected against the most common (Script kiddies, SQL injection …)

------------------------
6.4 - Back-up

Registry data are stored and secured using the real-time replication mechanisms of the production Database Management System (production DBMS).
In addition, a physical backup of the entire database must be performed at the same time as the back-up of the other components of the SRS.
To be compliant with the ICANN requirements, a data escrow deposit must be performed every day between 0:00 am end 12:00pm

------------------------
6.5 - Security management of network services

A strict partitioning into zones must be implemented in order to avoid interconnections between the external production, administration and backup networks.

Any internal and external attempts to access production servers must pass through a Firewall. They are recorded in a log file for later analysis. The detection of malicious code based on a regularly updated list must be performed at this level.

An intrusion detections system must be installed and running between firewall and production servers.

------------------------
6.6 - Monitoring operation of the System

Automated monitoring must be implemented. It must cover the hardware, software systems and production applications.
Any failure must be subject to a specific alert sent to the staff:
* on duty during office hours;
* on standby outside office hours;


------------------------
7 - Access Control

------------------------
7.1 - Business requirements for access control

Access to the information system requires prior identification and authentication. The use of shared or anonymous accounts must be avoided. Mechanisms to limit the services, data, and privileges to which the users have access based on their role at AFNIC and the Registry must be implemented wherever possible.

------------------------
7.2 - Control of network access

The internal network must be partitioned to isolate the different services and applications and limit the impact of incidents. In particular it is highly desirable to isolate services visible from the outside in a semi-open zone (DMZ). Similarly, access to the wireless network must be controlled and the network must be subject to appropriate encryption.

------------------------
7.3 - Control of access to operating systems

The production servers must be confined in secure facilities. Access must be restricted to authorized personnel only. The personnel in question are the members of the operating teams and their managers, IT personnel and those of the Security Manager.


------------------------
8 - Acquisition, development and maintenance of information systems

------------------------
8.1 - Cryptographic measures

Cryptographic measures must be implemented to secure the exchanges :
* between the workstations of technical staff and the access proxies to production servers;
* between the Registrars and the EPP server;
* between the DNS master servers and the resolution servers;
* to upload the records of the Escrow Agent.

------------------------
8.2 - Management of technical vulnerabilities

The technical configuration of hardware and software used must be subject to up to date documentation.
The changes in technical configurations must be constantly monitored and documented.
Security alerts involving updates and ⁄ or patches to production systems must be constantly monitored.
Application procedures must be documented and updated based on the recommendations of the designers of a component.


------------------------
9 - Managing incidents related to information security

------------------------
9.1 - Managing improvement and incidents related to information security

The crisis management procedure serves to mobilize at a sufficiently high echelon, all the appropriate levels of responsibility for taking decisions on the actions required to resolve the crisis and return to normal.
Each security incident must be analyzed under the cover of the Security Council and the recommendations, if any, are applied, checked and evaluated as required by the QMS.


------------------------
10 - IT Disaster Recovery Plan

The risk analysis must produce some inputs for the elaboration of a disaster recovery plan. That plan has to be established and regularly tested in order to maintain or recover Registry activity and make critical services available at the required SLA after an interruption or a crash of critical services of the Registry.


------------------------
11 - Integrating audits of the information system

Security audits are performed annually. They are launched on the initiative of the CTO or upon request from the ASC. They are carried out by independent bodies and relate to one or more of the essentials services of the Registry.

The ASC and the ASM control the implementation and the efficiency of these measures in the framework of S3 process (see section 2.1).



© Internet Corporation For Assigned Names and Numbers.