Application number: 1-1087-47153 for City of Paris

City of Paris

Ville de Paris
5 rue de Lobau
Paris 75004
FR

+33 1 42 76 40 40

+33 1 42 76 60 85

http:⁄⁄www.paris.fr⁄

Mr. Fabien BETREMIEUX

Registry Services Manager

+33 6 43 01 84 87

tas-paris@afnic.fr

Mr. Jean-Philippe CLEMENT

: Chargé de mission Technologies de lʹInformation et de la Communication (Officer in charge of IT and communications)

+33 1 42 76 43 76

jean-philippe.clement@paris.fr

The City of Paris is the public authority for Paris, the Capital City of France.

Under Article 72 of the French Constitution, the City of Paris is a ʺCollectivité Territorialeʺ and as such, is governed by its own local government. The current head of that government is the Mayor of Paris Bertrand Delanoë.
The ʺCode general des collectivités territorialesʺ (Articles 25-11-1 & s.) is the French national jurisdiction that specifically describes the legal status of the City of Paris (see attached extract of this legal code).

Not Available

Madame Anne HIDALGO
Première adjointe au Maire chargée de lʹurbanisme et de lʹarchitecture
Monsieur Bertrand DELANOE
Maire de Paris
Monsieur Christian SAUTTER
Adjoint au Maire chargé de lʹemploi et du développement économique et de lʹattractivité internationale
Monsieur Jean-Louis MISSIKA
Adjoint au Maire chargé de lʹinnovation, de la recherche et des universités

Madame Carine SALOFF-COSTE
Sous-Directrice du Développement Économique, de l’Emploi et de l’Enseignement Supérieur
Madame Valérie de BREM
Secrétaire générale adjointe chargée du pôle « économie et social »
Madame Véronique BÉDAGUE-HAMILIUS
Secrétaire Générale
Monsieur Alain BAYET
Secrétaire général adjoint chargé du pôle « fonctions support et appui aux directions »
Monsieur Bernard PIGNEROL
Délégué Général aux Relations Internationales
Monsieur Eric SPITZ
Directeur des affaires juridiques 4 rue Lobau Directeur des affaires juridiques 4 rue Lobau
Monsieur Jean-François DANON
Secrétaire général adjoint chargé du pôle «service aux Parisiens »
Monsieur Philippe CHOTARD
Secrétaire général délégué chargé du pôle « espace public »
Monsieur Vincent BERJOT
Directeur des Finances

PARIS

Not Available

The City of Paris (and its Registry Back-end Service Provider, AFNIC in partnership with CORE Internet Council of Registrars) ensured that there are no known operational or rendering problems concerning the applied-for gTLD string ʺPARISʺ.
Since the gTLD string ʺPARISʺ is an ASCII-only string, it is safe to assume that, just like with existing ASCII-only TLD strings like .com, .net or .de, no operational or rendering problems may be expected. In particular, the name consists only of ASCII characters that are already used for existing top level domains; all the characters in the name are even used in the leftmost position of existing TLD labels. In order to confirm this, the City of Parisʹ Registry Back-end Service Provider has conducted a thorough research regarding whether operational or rendering issues occurred for any existing ASCII-only top level domain in the past. The results of this research confirmed the assumption.
This means that bi-directional issues (like the ones described at http:⁄⁄stupid.domain.name⁄node⁄683) will not occur, also since the TLD string does not contain digits (which behaviour in bi-directional contexts can lead to rendering issues).
As the registry supports right-to-left scripts on the second level, the respective IDN tables were carefully crafted according to IDNA2008 standards to ensure that no rendering issues occur left or right of the dot (ʺ.ʺ) character separating the top and second domain name labels (which are the only labels under the registryʹs control).
Moreover, the gTLD string exclusively uses characters from a single alphabet, does not contain digits or hyphens, and it contains characters that are not subject to homograph issues, which means there is no potential for confusion with regard to the rendering of other TLD strings.
Finally, the City of Parisʹ Registry Back-end Service Provider set up a testing environment for the .PARIS TLD using the .PARIS target Registration System, including an EPP SRS, Whois and DNS servers, in order to conduct a series of tests involving typical use cases (like web site operation and e-mail messaging) for a TLD. The tests revealed no operational or rendering issues with any popular software (web browsers, e-mail clients) or operating systems.

The applied-for string will serve as the TLD for the City of Paris, Capital city of France. Paris is world famous as a center of arts, science, technology, culture, fashion, design and cuisine... The TLD is being applied for by the City of Paris, the public authority for Paris.

Through the TLD .PARIS, the City of Paris intends to provide specific content to Internet users from all over the world. The Internet today appears as a global medium where local parameters are not always clear or easy to identify. Estimates from major search engines place local search at around 30% of the total amount of search queries they handle. For the City of Paris, .PARIS is a way to help Internet users pinpoint Paris-specific content more easily, thereby improving their user experience.

The latest figures available (2010) show that 2.2 million people live in Paris and a total of 11.6 million inhabit the Greater Paris area. Paris is also home to 350,000 companies and 30,000 shops. Around 28 million people visit Paris every year (making Paris the number one tourist destination in the world), including some 17 million tourists from outside France. France remains the worldʹs leading tourism destination with 76.8 million visitors in 2010 according to the UNʹs World Tourism Organisation (UNWTO).In 2011, Roissy and Orly airports received 88.1 million passengers. In 2010 there were 13.6 million visitors to Notre Dame, 10.5 million at Sacré Coeur Montmartre, 8.4 million to the Louvre, 6.6 million to Eiffel Tower and 3.5 million at Centre Pompidou.
In the Greater Paris area (The bulk of Paris Area belongs to the French administrative Region “Île de France”, composed of 8 départements), there are 18 convention centers and exhibition grounds where 959 congresses and 384 exhibitions took place in 2010. 

The Greater Paris area has more than 71,000 companies whose businesses rely primarily on tourism. These companies account for 500,000 salaried jobs, including 47% in Paris, with growth of 2 to 3% per year in job creation. Tourism consumption is estimated at 16.7 billion euros for the greater Paris area (Ile de France).

Paris is referenced in billions of web pages, as shown by a search on the string ʺparisʺ carried out using any of the leading search engines.

There are more than 100,000 domain names registered in the leading gTLDs (COM, NET, ORG, INFO and BIZ) containing the word Paris.

According to figures released by the City of Paris, 80% of the Paris population are regular users of the Internet (versus 71% for France as a whole) and 45% surf using mobile devices (35% for France).

The .PARIS TLD aims to service both this local, national and international user base by providing a clearly identified domain on the Internet for the city.

The .PARIS TLD is intended as an open TLD with registrations rules that guarantee widespread usage by all Internet users, be they from Paris, or elsewhere. This TLD is designed as a highly attractive TLD, with projections in the order of 35,000 registrations in the first years of operation.

.PARIS has several goals:
 * To facilitate digital communications from, to and within the Paris Community.
 * To provide a platform for the urban development of the Paris Community in the digital space, including local digital services
 * To strengthen the image of Paris online.

The City of Paris intends to achieve these goals by:
 * Actively designing and developing the .PARIS TLD name space with a focus on the needs of the Paris Community, by involving cultural, welfare, business and public stakeholders.
 * Allowing registrations of second-level domains in the .PARIS TLD by individuals and organizations with a bona fide nexus to the Paris area.
 * Operating the .PARIS TLD under the stewardship of the City of Paris in consultation with the local public authorities of the Greater Paris area and private sector stakeholders.

(b) (i)

The .PARIS TLD is planned as the national and international digital territory for the City of Paris. The goal of .PARIS in terms of specialty is to focus on the needs of the Paris community. Service levels will match or exceed the high end of currently existing TLDs. The .PARIS registry will vigorously build and defend the reputation of .PARIS as a well-managed, orderly and progressive TLD for the Paris community.

(b) (ii)
The current Internet namespace has no City names, either as a gTLD or as a ccTLD. The .PARIS TLD is therefore innovative as it aims to bring the Paris identity to a unique web identifier. This is the first time a Capital city will have the opportunity of running a dedicated TLD and providing users with a unique area on the Internet. Currently, Paris only exists on the web as a subdomain of the French ccTLD Dot FR. Users do not have a clear defined area which they can link to Paris. The .PARIS TLD aims to remedy this.

As a name space specific to a metropolitan area with 12 million inhabitants and considerable economic and cultural significance, the .PARIS TLD fills a large gap in terms of consumer choice. From a competition standpoint, it creates a level playing field with respect to the market power of large unspecific TLDs. It is naturally differentiated from other TLDs both by its scope, by its governance model and by its intrinsic meaning. Innovation is greatly enhanced by the proactive structured development of the name space. The development of the TLD involves an open process with calls for proposals for purpose-built localized services based on designated portions of the .PARIS name space. This approach helps leverage the innovative potential that exists worldwide for the benefit of the Paris community and for the advancement of the global Internet.

(b) (iii) 

The TLD, operated by a public body for the common interest of Parisians and visitors⁄lovers of Paris worldwide, will offer the following advantages.

= Social =

 * Clearly identify the Paris community on the Internet.
 * Create a single, easily recognisable identity for Paris on the Internet.
 * Existing and new services can be tailored to fit local requirements and supervised by the City of Paris to ensure the public interest is upheld.
 * As the use of the Internet through mobile devices is already widespread in Paris, specific services aimed at this type of use can be introduced and clearly labelled under .PARIS. Mobile use of the Internet is a key factor in increasing the quality of access to services and information provide by a key tourist destination such as Paris.
 * Allow users to access these new services or create new services of their own through their operation of .PARIS web addresses.

= Image =

 * Running its own TLD strengthens Parisʹ image as a technology leader.
 * The .PARIS TLD is positioned as the official entry point on the Web for anything Paris-related, both for Parisians, local users and tourists.
 * The decision, by a major city, to operate its own TLD also sends a clear signal to the national and international business community that Paris is extremely technology friendly, thus helping to boost the regionʹs economic development.

= Security =

 * Operating its own TLD will give the City of Paris greater control over the use of the term ʺParisʺ on the Internet, as it pertains to the French Capital.
 * Technical and security evolutions can be taken into account in a timely manner on the Dot Paris platform.

= Citizenship =

 * Parisians will be able to signal their place of residence with a .PARIS domain name or email address.
 * Local businesses will also be able to make their geographic location clear.
 * Internet users with close links to Paris, be they business or personal, can reinforce them through a .PARIS domain name.

= Investment =

 * Operating the TLD may generate revenue for the City of Paris. As a public body, the City of Paris would use this revenue for the common interest of its citizens, as the profits generated are reinvested in the public services the city oversees.
 * The City of Paris has set a low registry price for .PARIS domains in the hope that registrars will sell .PARIS domains name registrations at a price that puts them within financial reach of the highest number of potential users.
 * Due to its intended low registration price, users of a .PARIS domain name would benefit from quick and easy ROIs in terms of image (link to Paris) and SEO indexing (increased visibility for their .PARIS web addresses).

= Legal =

 * As the name of a Capital city, Paris is a valuable term that needs to be protected in the interest of local citizens and visitors to the city alike. By operating its own TLD, the City of Paris would be able to monitor the use of the term Paris, as it pertains to the Capital of France, on the Internet.
 * The City of Paris would be better equipped to defend its intellectual property rights through its management of a dedicated TLD. One example of this is the definition of reserved names by the City of Paris as a registry operator, thereby precluding the rogue use of certain infringing terms which it is powerless to do under existing TLDs which are operated outside of its control.

Compared to most existing TLDs, the .PARIS user experience will bring domain names that are more predictable to users in terms of content and easier to remember. The community-based focus, the orderly launch process and strong intellectual property support ensure that users will generally find the services they are looking for under the names they intuitively tend to use for them. Users will also gain greater comfort when using variants. Users in the Paris community will be able to get accustomed to the predictability of .PARIS domain names. As a result, they will also be better equipped to avoid being tricked by typosquatting, pay-per-click or domain-for-sale pages.

(b) (iv)

The registration policies are differentiated between the pre-launch, launch and general availability phases. 

During pre-launch, projects and content provision commitments are actively sought and negotiated, especially for key public-interest portions of the name space. All potential registrants and mandate holders are subject to screening and thorough pre-validation. 

During the launch phase, all registrations are pre-validated; launch phase pre-validation depends on priority status (public service, trademark, no prior rights) but will always involve community nexus. 

At general availability, community nexus is subject to post-validation by way of an extensive compliance program. The ongoing compliance program will regularly be adapted to current needs based on experience and audit findings. Community nexus validation combined with strong protection of trademarks helps stamp out cybersquatting and abusive registrations.

(b) (v)

The protection of privacy and confidential information of registrants and users will comply with French Law and the European Data Protection Directive, as well as the ICANN standards. Within the bounds of applicable regulations, the registry will implement anti-data mining measures by way of rate limitation, authenticated access or white-listing⁄black-listing, as well as tools to prevent unauthorized recourse to repetitive automated access.

= Outreach = 

A full PR and communications campaign was initiated as soon as the City of Paris announced its intention to apply for .PARIS. Paris was the first major city to commit to ICANNʹs new gTLD program in June 2008, as the ICANN Board approved the GNSOʹs PDP on new gTLDs.

Media and PR campaigns have helped raise awareness of .PARIS, making the TLD one of the best known potential new gTLDs set to come out of ICANNʹs program.

In 2010, a dedicated website was launched to explain .PARIS to the community. The website is at http:⁄⁄SoutenonsPointParis.fr (support .PARIS) and features an online support page where Internet users can sign up to show their support for the TLD.

Dedicated Twitter, Facebook and Flickr accounts have also been opened.

A special event has already been hosted at the Paris town hall, personally attended by the Mayor of Paris Bertrand DELANOE, in support of the .PARIS TLD.

The .PARIS TLD has outreach programs tailored to each of its launch phases. 

Pre-launch will involve calls for projects by innovators and pioneers aimed at increasing the usability of the .PARIS TLD with a focus on the needs of the Paris community. Once these domain names are active, they become an outreach mechanism in their own right, because they establish the touch-and-feel of the .PARIS TLD in the minds of the users. 

The launch phases will involve outreach mechanisms that specifically leverage participation by the local public services, locally relevant trademarks and local actors. 

Promotion codes distributed through community-specific channels are a form of outreach available at any time. They are also a low-cost method to achieve community nexus and to prevent abusive registrations.

(c)
The pre-launch, launch and ongoing registration phases of the .PARIS TLD are designed to minimize social costs and negative externalities. They protect registrants and potentially affected parties while maximizing the value of the name space to its registrants and users. 

This approach is based on the premise that extensive screening efforts by the registry in the early stages will create a fair and orderly name space with lower compliance costs in the long term. 

In phases and areas where the first-come-first-served principle tends to yield perverse results, alternative modes are used. These include:

 * A pioneer name program and name space mandate program. 
 * A long launch phase based on domain applications and contention resolution.

Pioneer name program and name space mandate program

These programs adjudicate domain names based on an open and transparent project selection process. This process is highly economical in terms of social costs and yields substantial external benefits. 

The pioneer name and name space mandate programs are part of the .PARIS outreach program. It begins before delegation of the TLD. In terms of workload, it mainly affects proposers who themselves are required to demonstrate support for their projects. Support will be required to come from the segment of the community concerned with the respective portion of the name space. Given the high value of the resulting online resources for the community and the public interest, and given the economic benefits that can be derived from their operation, the administrative effort is largely justified.

To further protect affected parties, all adjudications in name space mandates have a safety-valve clause, allowing for later adjustments based on community input. The principle of the safety-valve is that affected parties can obtain adjustments to a component of a mandate if they propose (and commit to) an improved use of the underlying domain names from a public interest perspective. 

= Launch phase =

The launch combines the so-called “sunrise” and “landrush” processes simultaneously in one phase. The use of domain applications instead of domain registrations means that the registry accepts multiple applications for the same domain name (by contrast, only a single registration can exist for a given domain.) In this way, contention resolution can take place without time pressure in a transparent, fair and orderly manner.

During the launch phase, the time stamp of domain application is not relevant for priority. Adjudication is based on priority differentiation and, in case of equal priority, through a largely automated, multi-step contention resolution process. This mechanism has the lowest aggregate social costs and the highest aggregate public benefits while individually protecting each stakeholder from the risk of an excessive burden.

All applications are published on the Whois service. Applicants mark their prior rights, if any, in the application. There are three fundamental classes of priority: public service (highest), trademark (second), and no-prior-right (third). 

For a given domain, the highest priority applications will be validated with respect to the claimed priority right. If there is more than one application for the same domain in that priority class, a contention resolution process begins. The contention resolutions process allows agreement between contenders (withdrawal and refund of application), random selection (if all contenders agree), mediation and arbitration and, as a tie-breaker of last resort, auction. 

In most circumstances, the agreement or auction are the cheapest solution for affected parties and are likely to be selected. It is possible, however, for a party to avoid auction by requesting arbitration panel decision. An arbitration panel decision will involve in-depth analysis, the cost of which is borne by the requesters. Unless prior rights provide sufficient grounds for a panel adjudication, the key criterion is the applicant’s contribution to the value of the .PARIS name space in the public interest. 

The options available to a contender are thus designed to promote quiet resolution by way of withdrawal, mediation or auction. Thanks to automation this minimizes efforts for all parties. 

= Ongoing registration phase = 

Registrations are checked in a post-validation process and subject to an enforcement program based on statistically targeted random investigation and complaint follow-up. This program minimizes both costs to registrants and third parties. In particular, it strongly diminishes the attractiveness of rights violations, abuse or malignant behaviour. Having been preceded by a controlled launch phase, the validation and enforcement workload faces no resource bottleneck and thus achieves a high degree of credibility, further dissuading abuse from the start. This mode of operation has a strong positive side effect in the interest of trademark holders. 

(c)(i)
As described above, during pre-launch and launch phases, the first-come-first-served principle is NOT applied. Adjudication by auction is one of the solutions available to the parties in the context of the contention resolution process.

(c)(ii)
The focus of the .PARIS TLD is the bottom-line cost to registrants and stakeholders. This takes into account all burdens, including the effort needed to register or the potential alternative cost to obtain a name on the secondary market. The direct per-unit cost is merely a component of the bottom-line cost.

The bottom-line cost is greatly reduced by avoiding contention between legitimate community-based applicants and speculators. Community-specific promotion code programs are used offer registrations at low cost. This is a way to avoid perverse effects of low prices, such as speculation with ultimately high costs to registrants, large-scale confusion and waste of the name space, or cybersquatting. 

The name space mandate programs have special terms in order to ensure that key portions of the name space are used in the public interest.

(c)(ii)
The .PARIS TLD will not be based on contractual clauses regarding price escalation between the .PARIS Registry and its registrars.

The .PARIS business plan is designed to avoid any future necessity to increase registry price in real terms. The fundamental principle is prudence: starting from conservative price levels and gradually lowering them. This method ensures sufficient financial reserves, favours optimal allocation of domain names, helps prevent misuse and supports an orderly registration process.

Yes

The .PARIS TLD belongs to the Paris community. The following clauses (A), (B) and (C) describe the delineation of the Paris community and corresponding policy principles of the .PARIS TLD
(A) The Paris community comprises individuals and legal entities with a bona fide presence, direct or indirect, in the Paris area or in Paris as the capital of France. The Paris area is the metropolitan area of Paris and its geographic environment. A bona fide presence in the Paris area may be:
* residence in the Paris area, or
* the pursuit of lawful business activities in the Paris area, or
* the pursuit of cultural activities in the Paris area, or
* any other kind of direct or indirect presence that is generally accepted as legitimate for, and conducive to the welfare of, the Paris area.
(B) Registration of domain names under the .PARIS TLD is restricted to members of the Paris community and subject to the further requirement that the domain name registrant’s presence in the Paris area and the registrant’s use of the domain name must be:
* of a kind that is generally accepted as legitimate and
* conducive to the welfare of the Paris area and
* of commensurate quality to the role and importance of the respective domain name and
* based on good faith at the time of registration and thereafter.
(C) The City of Paris acts as the central representative organization for the Paris community with regard to the .PARIS TLD, in consultation with the stakeholders of the Paris area and of Paris as the capital of France.
* How the community is delineated from Internet users generally.
The Paris Community relates to the geographic area commonly referred to as Paris or the Paris area, a described in above. The Paris area comprises the geographic urban areas of Paris, France. It is clearly recognizable by urban infrastructure, such as the local transport network in and around the City of Paris.
The delineation described under (A) above matches the reality of the Paris community as it has existed since the advent of Paris as a modern metropolis.
The term “Paris area” refers to the geographical area of Paris and its surroundings, as in the popular meaning of the expression “région parisienne” in French or “Paris area” in English. Equivalent expressions are “Paris metropolitan area” in English or “région urbaine de Paris” or “agglomération parisienne” in French. The urban area has grown over time: the city grew beyond its fortifications and customs controls at its gates were abolished. The modern Paris area includes, but is not limited to, the territory of the City of Paris, and is largely (but not entirely) situated within the boundaries of the Île de France administrative region. As any modern metropolitan area, the Paris area is defined by practical realities of urban life rather than administrative borders. It comprises the places associated with Paris in the popular use of the name for cultural, economic, geographic, political and other generally accepted purposes. (For instance, an airport or university campus is generally accepted as being part of Paris even if located outside of the city territory.)
A Paris community has existed for time immemorial. For as long as it has existed, those who belonged to it were those who had a bona fide presence in the urban area. With the advancement of civilization, new forms of presence (such as business or culture) have become generally accepted. A bona fide presence in the Paris area may be direct or indirect, on the basis of domicile, activity, cultural links or any other constructive commitment to the Paris area. It may be emanating from the area or be directed to the area.
Given the vast scope of a modern metropolitan community, community membership always depends on context. This is why, for the purpose of domain registrations, the strength and quality of the registrant’s nexus must be commensurate to the role and importance of the domain name to the Community.
In other words, a bona fide presence in the Paris area (and thus community membership) is a necessary condition, NOT in itself a sufficient condition for the right to hold any imaginable .PARIS domain name. As the policy principles under (B) above description show, there are additional requirements specific to the intrinsic role and importance of the domain name in question. They concern in particular the nature of the registrant’s presence in the Paris area and the registrant’s use of the domain name.
The wish to hold a .PARIS domain name is not in itself a sufficient indication of a bona fide presence in the Paris area. Furthermore, if a person has been able to register a domain name in .PARIS, this does not in itself entitle that person to register any imaginable other .PARIS domain name.
= How the community is structured and organized =
As any other modern metropolitan area, the Paris community is very organized. The Paris area belongs to a single, highly integrated community. Because of if its importance and size, the community’s organization involves a number of public bodies and authorities on several levels (such as régions, départements and arrondissements), treaties between public bodies, joint investments in public infrastructure companies, public-private partnerships, coordinated policies and legal frameworks that define the duties and prerogatives of each body. The public bodies are established by law and their representatives are democratically elected by universal suffrage. It goes without saying that private companies and cultural or welfare organizations also belong to the organization of the community.
The bulk of the Paris Area belongs to the French administrative Region “Île de France”, composed of 8 départements. Certain parts of the Paris area extend beyond the administrative boundaries of the Île de France Region.
= When the community was established =
The City of Paris (and therefore the Greater Paris Area) has existed as an organized community since antiquity, having grown naturally over time. It has been known as by the name of Parisii or Paris since the late stage of the Roman Empire.
As described above, the Paris area in the generally accepted sense extends beyond the territory of the City of Paris. The establishment of the public bodies of Paris community is not the result of a single formal act, but multiple steps including many formal acts and gradual developments defining their current form and their relationship with community members and between each other. Formally, their establishment defined in the French Constitution and in French law as described under Question 8.
The activities of the Paris community are:
* the shared concerns and pursuits of the residents and stakeholders of the Paris area (along with their organizations or public bodies)
* the shared use of the infrastructure and services of the Paris area, such as transport, telecommunications, as well as culture, education, welfare and leisure,
* the role of Paris as national capital of France.
The Paris community includes extensive activities in the digital world specific to the Greater Paris Community, both in the form of e-government services and public authorities’ contributions to the development of information society. The .PARIS TLD is designed to be directly related to the activities of the Paris community.
= The current estimated size of the community, both as to membership and geographic extent: =
The population of the Paris area is in the order of 12 million inhabitants. The geographic extension of the Paris area is estimated at 12,000 square kilometers.

The applicant is the City of Paris itself. The City of Paris is the central legitimate authority for the name of Paris. Its democratically elected local government has the duty to make key decisions regarding the use of the name of Paris in the interest of all community stakeholders.
= Relations to any community organizations: =
As the Paris area extends beyond the administrative borders of the City of Paris. The generally accepted meaning of the name comprises the entire Paris area. The Paris area and the name of Paris have a natural focus on the center of the area, the City of Paris.
The City of Paris has a special responsibility towards the entire Paris area with respect to the use of the name of Paris. For this reason, the City of Paris assumes the stewardship of the .PARIS TLD in consultation with public authorities and private sector stakeholders of the Paris area.
In doing so, the City of Paris builds upon established and proven relationships between the respective public bodies, defined by law and⁄or developed over time for the management of the vast public infrastructure jointly operated and developed by them.
= Relations to the community and its constituent parts⁄groups: =
The City of Paris and the other départements of the Greater Paris Area collaborate with a wide array of community organizations for economic development, welfare, culture, education and leisure. This includes community organizations that specialize in the development of the digital economy, e-government and information society. The City of Paris will build upon existing relationships to set up an effective and transparent governance process for the .PARIS TLD.
= Accountability mechanisms of the applicant to the community: =
The local government bodies of the City of Paris are democratically elected by their residents. The governance process for the .PARIS TLD is rooted in the public accountability mechanism of the City as defined by the Law. In addition, the .PARIS TLD will have specific policy-oversight and consultation mechanisms.
As the Mairie de Paris (City Council) itself assumes the stewardship of the .PARIS TLD, the ultimate line of accountability from the .PARIS governance body goes through the office of the elected Mayor and Deputy Mayors to the electorate. Additional lines of institutional accountability exist through the Regional Council of Île de France, itself elected by universal suffrage.

As described under Questions 18(a), the purpose of the .PARIS TLD is to:
* facilitate digital communications from, to and within the Paris Community;
* provide a platform for the urban development in the digital space of the Paris Community.
* strengthen the image of Paris in the on-line world.
= Intended registrants in the TLD: =
The intended registrants of the TLD include the residents of the Paris area, businesses active in the Paris area, contributors to the cultural life of the Paris area as well as any other legal entities or individuals who contribute to the welfare of the area.
= Intended end-users of the TLD: =
The intended end-users include the general public with an interest in Paris. This comprises one the one hand the public in the Paris area and on the other hand the public world-wide with an interest in Paris.
= Related activities the applicant has carried out or intends to carry out in service of this purpose. =
All the activities of the City of Paris are related to .PARIS TLD serve the community-based focus of the TLD. They involve the active development of the name space and other activities to support community-based eligibility and name selection processes described under Question 20.
= Explanation of how the purpose is of a lasting nature: =
The purpose of the .PARIS TLD if of a lasting nature because it exactly matches the popular use and generally accepted meaning of the name ʺParisʺ. The lasting nature of City of Paris, of the Paris area and of the Paris community are established beyond and doubt, as is their intimate association with the name of Paris.

The .PARIS TLD serves the Paris community. The Paris community comprises persons and legal entities with a bona fide presence in the Paris area. The Paris area is the urban area of Paris, France.
= Relationship to the established name of the community: =
The TLD string “.PARIS” matches the name of the community, Paris, in the generally accepted sense of the word, in French, English and all other internationally used languages.
= Relationship to the identification of community members: =
The identification of community members is based on the Community delineation described in the response to Question 20(a), namely clause (A) as follows:
(A) The Paris community comprises individuals and legal entities with a bona fide presence, direct or indirect, in the Paris area or in Paris as the capital of France. The Paris area is the metropolitan area of Paris and its geographic environment. A bona fide presence in the Paris area may be:
* residence in the Paris area, or
* the pursuit of lawful business activities in the Paris area, or
* the pursuit of cultural activities in the Paris area, or
* any other kind of direct or indirect presence that is generally accepted as legitimate for, and conducive to the welfare of, the Paris area.
Community membership is a necessary condition for the right to hold a .PARIS domain name, but is not in itself a sufficient qualification, as is also described in the response to Question 20(a), namely the policy principles in Clause (B) as follows:
(B) Registration of domain names under the .PARIS TLD is restricted to members of the Paris community and subject to the further requirement that the domain name registrant’s presence in the Paris area and the registrant’s use of the domain name must be:
* of a kind that is generally accepted as legitimate and
* conducive to the welfare of the Paris area and
* of commensurate quality to the role and importance of the respective domain name and
* based on good faith at the time of registration and thereafter.
= Any connotations the string may have beyond the community: =
The word “Paris” does have minor other meanings or connotations. None of them have any remotely comparable significance to that of Paris referring to the urban area of Paris, France.
The fact that “Paris” was also the name of a character in Greek mythology has cultural importance but no comparable practical significance in modern life.
The string “paris” is the plural form of the French word “pari” (meaning wager, bet or gamble). It has no comparable significance to that of Paris denoting the metropolis.
There are smaller places in the World by the name of “Paris”. All of them bear their name in reference to the Paris metropolis in France.
Depending on the context, the word Paris can designate a wider or smaller area (ranging from central Paris to the entire metropolis), as is the case with any place name. This has no practical consequence because these usage variants of the word all point to a key aspect of the same community.

As described in the response to Questions 20(a), two types of conditions must be fulfilled for the right to register a .PARIS name. These are:
(A) community membership (bona fide presence in the Paris area) and
(B) the additional requirements that
* the presence in Paris area and use of domain are generally accepted as legitimate;
* the presence in Paris area and use of domain are conducive to welfare of the Paris area;
* the presence in Paris area and use of domain are commensurate to role and importance of domain;
* presence in Paris area and use of domain are based on good faith at registration and thereafter.
These conditions must always be fulfilled. The strength of the validation is kept in line with the importance of the underlying domain name base on the assumption that a typical user would reasonably make.
Registrants are required to have an administrative contact in the Paris area. This is verified in part automatically (through the postal code in the administrative contact record and by a human eyes review pre-validation or post-validation. The administrative contact may be any person or entity having received and accepted the mandate to act as such for the respective domain. (The registrar may act as administrative contact.) Any communications addressed to the administrative contact are deemed to have been brought to the attention of the domain holder. Validation checks include machine and human verification of address accuracy.
The validation may be assisted through pre-identification of potential registrants using existing community channels, in particular through promotion codes.
After the launch phase, the validation mode goes from pre-validation to post-validation and later to statistically targeted random validation, backed up by an ongoing enforcement program. Validation will include checks about the registered domain name actual or intended use. As far as intended use would be declared by the registrant, a false statement of intended use is an indication of bad faith and can be the basis for the suspension of the domain name.
The validation and enforcement program are supported by an integrated issue tracking system. This system allows validating agents and personnel to cooperate and interact with the registrant. The system keeps track of decisions made by the agents and stores supplemental documentary evidence that may be supplied by the registrants.
= Name selection: what types of second-level names may be registered in the gTLD? =
The fundamental rule on which name selection is based is part of the policy principles: the registrant’s presence in Paris area and use of domain must be commensurate to role and importance of domain registered.
The role and importance of the domain name is based on meaning an average user in would reasonably make in the context of that domain name.
This criterion also applies to the strength of the documentation or proof required of the registrant.
Pre-defined of the name space, especially names with significance for Paris area from a public service or public interest standpoint, is developed through special programs with strong selection processes, based on proposals made by parties interested in providing content on such domain names. This process not only cover the identity and legitimacy of the party entrusted with the operation of the domain(s), but also a defined obligations with respect to the content to provide for the benefit of the public.
= Content⁄Use: what restrictions, if any, the registry operator will impose on how a registrant may use its registered name? =
As described in the response to Question 20(a), not only the registrant’s Paris presence but also the use of the domain must be:
* generally accepted as legitimate
* conducive to welfare of the Paris area.
* commensurate to role and importance of domain.
* based on good faith at registration and thereafter.
This is verified on the basis of:
* the intended use statement supplied by the domain registrant
* the ongoing enforcement program.
= Enforcement: what investigation practices and mechanisms exist to enforce the policies above, what resources are allocated for enforcement, and what appeal mechanisms are available to registrants? =
The purpose of the enforcement program is to protect the credibility of the .PARIS TLD for its local in international public. In particular, upholds the community-based purpose of the .PARIS TLD and helps prevent misuse or malicious behaviour.
The enforcement program is based on statistically targeted random investigations and on a complaint follow-up process. The statistical targeting is strongly automated and involves the use of search engines and the analysis of registry data related to behaviour of registrants.
Depending on the type of misuse to be investigated, web site content or content sent to victims of abuse will reviewed and analysed by investigators.
Enhanced investigation takes place if the registrant has a bad track record in terms of compliance with the rules of the .PARIS TLD. Other violations of public record (such as UDRP or URS cases) will also be taken into account.
If the actual or intended use cannot be deemed legitimate or has a negative impact on the welfare of the Paris area, the registration is rejected. If content or use of an existing .PARIS domain demonstrates that the registrant has shown bad faith, the domain name is suspended.
If a registrar is complicit with systematic violations of the .PARIS policies or causes an unacceptable burden for the validation and enforcement program by negligence, the registry can restrict that registrar’s access to the new registrations, subject its inventory of .PARIS domains to enhanced investigation and require it conduct its own post-validation program.
An appeals process is available for all administrative measures taken in the framework of the enforcement program. The first instance of the appeals process is managed by the registry service provider. The City provides the second and last instance of an appeals process by itself or entrusts it to an alternative dispute resolution provider. The charter of the appeals process is promulgated by the City of Paris.

Not Available

Yes

-Rules applicable to the protection of geographic names at the second and other levels in the applied-for gTLD :

In accordance with GAC advice on geographic names at the second level, the registry operator will put the following names on the reserved list:
-The short form (in English) of all country and territory names contained on the ISO 3166-1 list, including the European Union, which is exceptionally reserved on the ISO 3166-1 List, and its scope extended in August 1999 to any application needing to represent the name European Union:
http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU
-The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World. This lists the names of 193 independent States generally recognized by the international community in the language or languages used in an official capacity within each country and is current as of August 2006: 
http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄ungegn⁄docs⁄pubs⁄UNGEGN%20tech%20ref%20manual_m87_combined.pdf
 -List of UN member states in 6 official UN languages prepared by the Working Group on Country Names of the United Nations Conference on the standardization of Geographical Names: 
http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄9th-UNCSGN-Docs⁄E-CONF-98-89- Add1.pdf

However, the registry operator recognises that there may be cases where a request to register and use a geographic name at the second level should be considered valid.

Examples of such cases are:
-The City of Paris itself may wish to register a 〈geographic-name〉 .PARIS domain for its own use as part of an official event organised in Paris and referencing the geographic region in said domain name. For example, Paris is often host to celebrations of the culture and language of another country.
-Cultural centers located in Paris may wish to highlight their links to the geographic region they represent (e.g.: the Chinese cultural center in Paris - http:⁄⁄www.cccparis.org⁄).
-The geographic regionʹs public authority wishes to register the domain name for its own use.

In all cases, whether it is the registry operator wishing to register a geographical name for official or public service use, or whether it is an individual applicant, the City of Paris is committed to obtaining the approval of the relevant authority.

For registration requests from the relevant public authority, the registry operator will put in place the procedure agreed between the GAC and Afilias for the Dot INFO gTLD as referenced in the letter written by Mohamed Sharil Tarmizi, GAC Chair, on Sept 9, 2003.

For any other request to register a geographic name, the applicant will need to provide registry operator with proof of non-objection or support from the relevant public authority. Once this has been submitted and verified, requests of this kind will be handled on a case-by-case basis only by registry operator.

Registry operator does plan to monitor use of geographic names below the second level (i.e. subdomain used by a .PARIS domain name registrant), as the procedures that would be needed to monitor this are considered too complex and expensive. Traditional dispute resolution procedures or legal procedures exist to address such cases.

-Technical implementation of the protection of geographic names:

Technical protection of terms:

The registry uses its own reserved terms database. The purpose of this database, in addition to protect the defined set of terms, is to allow actions (creations, updates, deletions), user rights (consult or edit) and traceability (history of actions) for each terms it contains.

During the registration of a domain name, the checker placed on the Shared Registry System (SRS) uses two types of checks on the requested terms. The first type of checks is based on syntax, the second one, is based on semantics. The reserved terms database is part of the second type of tests, based on semantics.

The reserved terms database is used in the Shared Registry System (SRS) during its semantics checks only if the domain name request has successfully passed the syntax checks.

The database table allows to classify the terms is contains by categories. The categories allow the registry to identify different types of terms (geographic names, religious terms, cultural...). In the case of geographic names the categories in the database allow subclassifications such as country names or city names.

The checker placed on the SRS applies the semantics checks to a domain name request using the registry’s policies translated into technical rules. The SRS checker uses the reserved terms database to verify the presence or not of the term in its table and acts accordingly. If the term and its category are present in the database the SRS checker will apply the registry’s policy of blocking the registration unless a valid authorization code is presented.

E.g: If “france” is requested by a registrar for registration without a valid authorization code the SRS checker will verify if the term and its category are present in the reserved terms database. The database will indicate that “france” is present in its tables under the “country” category. The SRS checker will then reject the creation request.

Unblocking a reserved term through an authorization code mechanism:

In order to create a domain name containing a reserved term for a registrant, registrars must fill out an online form protected by a captcha code. This form requires the registrar to fill out the requested domain name, the registrant information (nic-handle) and the reason or legitimate interest within a maximum of 4000 characters.

The reserved term request will automatically be sent to the registry’s back office into a queue for human validation by one of the registry’s validation agents. If the legitimate interest of the domain registrant is enough evidence that the domain creation complies with the registry’s policies the validation agent will generate an authorization code that will be sent by email to the registrar that made the request.

For security reasons the registrar’s email address on which the authorization code is sent to is the one defined as the NOC email address.
For additional security reasons the registry has decided that this authorization code is valid on the SRS for a maximum of 15 days. After 15 days the authorization code will expire and a new request will be necessary to retrieve a new authorization code.
The code generated by the registry’s validation agent can only be used for a domain name creation of the requested term for the requested registrant by the requesting registrar. Meaning that an authorization code cannot be used by another registrar or for another holder (identified by its nic-handle).

In case the request does not comply with the registry’s policies or if the given information is not sufficient to generate an authorization code, the validation agent will ask the registrar for complementary information. The registrar has 15 days to answer and provide sufficient information and or complementary documentation to the registry’s validation agent. After 15 days without sufficient information or documents, the authorization code request is abandoned.

Once the registrar receives an authorization code from the registry’s validation agent, the registrar has 15 days to initiate a creation operation on the requested reserved term. This authorization code is fully compatible to the registry’s EPP interface and is used during a creation operation as the auth_info code (see question 24 on EPP).

When the domain name creation operation with the valid authorization code is initiated by the registrar the SRS checker will automatically verify the code, the holder and the requesting registrar with the information contained in the registry’s back office. If the data is correct the creation operation will be processed like any regular domain name creation.

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 - Internationalized Domain Names
7 - DNS Security Extensions (DNSSEC)
 7.1 - Registrar Services
 7.2 - Signing Activity
8 - Other relevant services
 8.1 - Security and Redundancy
 8.2 - Consensus Policy Compliance


------------------------
1 - Receipt of data from registrars concerning registration of domain names and nameservers : Shared Registration System (SRS)
 
Operated by AFNIC in partnership with CORE, the .PARIS 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 .PARIS 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 .PARIS 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 .PARIS 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 : registrant, 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.

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 - Internationalized Domain Names

Based on AFNIC’s Back-end registry’s operation experience, the .PARIS TLD will allow registration of IDN domain names in full compliance with RFCs 5890 to 5893 and based on the character set described in detail in our answer to Question 44 (IDN). This feature will be available upon launch of the TLD and will be implemented following the policies presented in detail in our answer to Question 44 (IDN). For the purpose of clarity, a brief summary of this information is presented below.

The list of characters includes the French language as well as several other regional languages in use in France : Occitan, Breton, Frankish, Reunion Creole, Catalan, Corsican and Guadeloupe Creole. The list consists of some of the characters of the Latin1 standard (ISO-8859-1) and the Latin9 standard (ISO-8859-15), respectively in Unicode Latin-1 Supplement and Latin Extended-A blocks.
Each domain name registration is autonomous : the registration of an ASCII domain name and the registration of one of its diacritic variants are independent. The actual registered domain name is the only one to be effectively registered and published by the Whois and DNS Services.
However, the registration of a given ASCII or IDN domain name leads to a default preference to its registrant (original registrant) for the subsequent registration of any of its diacritics variants. Any of these variants can be registered normally by the original registrant at any time. Other registrants are required to request a specific authorization code delivered by the Registry Operator (as described in Question 44 (IDNs)) before they can proceed to the registration of such names. This policy applies whether the original registrant initially applies for an ASCII domain name or a diacritic variant of that ASCII domain name. In the latter case, the ASCII name is subject to the same preference policy than the other diacritic variants of the domain name.


------------------------
7 - DNS Security Extensions (DNSSEC).
 
AFNIC registry services fully support DNSSEC and will sign the .PARIS TLD zone from initiation into the root servers. 

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

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

------------------------
8 - Other relevant services

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

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 .PARIS 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 are fully dedicated to the .PARIS TLD.

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

It is important to note that at the applicative and system level, AFNIC’s SRS is fully dedicated to the .PARIS TLD.
 
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 :

= 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 26 ( Whois). 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 300 requests⁄minute
 * routine ongoing operations : up to 72,000 requests⁄day

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

The targeted TLD size being approximately 35,000 domain names after 3 years of operations and the expected peak transaction rate being 300 requests per minute during the launch phase, 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 Administratror 0.50 man.day
Network Administrator 0.50 man.day
System Administrator 0.50 man.day
Software Developper 2.00 man.day
Database Engineer 2.00 man.day
Software Engineer 4.00 man.day
DNS Expert Engineer 2.00 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 10.00 man.day
Database Administratror 4.00 man.day
Network Administrator 4.00 man.day
System Administrator 4.00 man.day
Software Developper 20.00 man.day
Database Engineer 3.00 man.day
Network Engineer 3.00 man.day
System Engineer 3.00 man.day
Software Engineer 3.00 man.day

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_create_command_example.pdf]
Diagram : EPP client create command and server answer 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 followed by standard EPP server create command answer compliant with RFC 5731. Parameters sent in the answer are result code, message, creation and expiry date, and client and server transaction ID.

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_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 : optional 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.2 - Command extensions

 ------------------------
 4.3.2.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.2.2 - EPP Transform Commands

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

 ------------------------
 4.3.2.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.2.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.2.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 Administratror 0.50 man.day
Network Administrator 0.50 man.day
System Administrator 0.50 man.day
Software Developper 2.00 man.day
Software Engineer 4.00 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 8.00 man.day
System Administrator 3.00 man.day
Software Developper 8.00 man.day
Software Engineer 3.00 man.day

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 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, registrants, 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 : registrant, 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.

 ------------------------
 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 registrant 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, using classical round robin implementation, and 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 network infrastructure is the same as described in the global architecture referred to below and described in Question 32 (Architecture). No specific dedicated switch or router is to be considered.

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

To enhance resiliency of the RDDS service a secondary RDDS server is hosted by AFNIC’s partner CORE (Internet Council Of Registrar). This server is synchronised in real time as described in section 7 - Interconnectivity and offers an additional availability ressource.
 
In addition, AFNIC servers are fully dedicated to the .PARIS TLD.

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

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

It is important to note that at the applicative and system level, AFNIC’s RDDS is fully dedicated to the .PARIS TLD

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 only 1 TLD.

= 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 servers
 * 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 requests ⁄ 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. 

Secondary CORE Whois server : our partner’s secondary Whois server is continuously synchronized with the registry database via a VPN connection. A special communication protocol (ʺWhois feedʺ) is used to supply information about objects that have been created, modified or deleted in the SRS to all connected Whois servers in a timely fashion.
As soon as changes to the registry database have been made persistent, these changes are forwarded to CORE Whois servers. The Whois servers update their own database with the data and provide the new information to the public. This way, changes to the registry will become visible on this additional Whois server typically in less than a minute. The near-realtime update for Whois data
resulting from this mechanism stays in accordance with the related performance specifications.
The Whois feed protocol has been carefully designed to allow a graceful recovery from temporary SRS⁄Whois disconnections. In case of a communication problem or a maintenance of the Whois server, changes that occurred since the last successful update are automatically identified and
transferred.

= 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 :
 * launch phase (including sunrise if applicable) : up to 540 requests⁄minute peak
 * routine on going operations : up to 130,000 requests⁄day

It 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 35,000 domain names with a provision for up to 540 requests per minutes during the launch phase, 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 Administratror 0.50 man.day
Network Administrator 0.50 man.day
System Administrator 0.50 man.day
Software Developper 2.00 man.day
Software Engineer 1.00 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.

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

Operations Specialist 6.00 man.day
System Administrator 2.00 man.day
Software Developper 4.00 man.day
Software Engineer 3.00 man.day

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

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

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

[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 2.00 man.day
Software Engineer 4.00 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 4.00 man.day
Software Engineer 6.00 man.day

Table of Contents


1 - Rapid Takedown Policy for Cases of General Malicious Activity
2 - Rapid Takedown Policy for Cases of Phishing
3 - Abuse Single Point of Contact
4 - Prevention of Domain Name Tasting or Domain Name Front Running
5 - Prevention of Domain Name Sniping (Grabbing)
6 - Prevention of Orphaned Glue Records
7 - Preventing Use of Reserved, Invalid, Illegal or Otherwise Unsuitable .PARIS Names
 7.1 - Rule Engine
 7.2 - Pattern matching and fuzzy string comparison
8 - Domain Data Access Control
 8.1 - Prevention of Whois Data Mining
 8.2 - Prevention of Unauthorized Data Modifications
9 - Whois Accuracy
10 - Resources
 10.1 - Initial Implementation
 10.2 - Ongoing maintenance



The .PARIS Registry will establish thorough and effective methods to prevent abuse of .PARIS domain names, .PARIS registrant data or the associated infrastructure, as well as to mitigate any impact from such abuse (should it occur despite the preventive measures). In order to achieve this, the .PARIS Registry is committed to deploy extensive organizational and technical measures. The most salient examples of these measures are described below.


------------------------
1 - Rapid Takedown Policy for Cases of General Malicious Activity 


The .PARIS Registry is committed to closely collaborate with law enforcement authorities and security agencies in order to take quick action in case a .PARIS name is reported to be involved in malicious activity. For this purpose, a ʺRapid Takedown Policyʺ is established that :


 * identifies cases of malicious activity, 
 * defines ways for the registry to be notified of such activity (e.g. via a dedicated web site, e-mail address or phone hotline), 
 * defines clear and consistent procedures to quickly stop the malicious activity (after the activity was confirmed and impact of the measures has been assessed), 
 * defines related service levels (e.g. with respect to the maximum time the registry may take to respond to takedown requests). This time limits will never exceed 14 business days in the case of less urgent cases, and not exceed 24 hours in the most urgent cases such as phishing.
 * defines rules regarding the notification of involved parties (registrant, administrative contact, technical contact, registrar, informant), 
 * defines ways to appeal against any measures taken (through the general Eligibility Restrictions Dispute Resolution Procedure as is the case for all appeals against Registry decisions, but with panelists that are specialized in Security and Malicious Conducts).
 * defines how cases covered by the policy need to be documented and reported. In this context, cases of malicious activity may include (but are not limited to) :
 * wrong, invalid or harmful DNS setup (e.g. pointers to false IP addresses), 
 * use of trademarked or otherwise reserved names without proper rights, 
 * use of the domain in actions that affect the stability and security of the Internet (e.g. in Denial of Service (DoS), Distributed Denial of Service (DDoS) attacks or botnets) 
 * use of the domain for the distribution of malware (such as computer viruses, worms, Trojan horses, spyware or rootkits) 
 * use of the domain for phishing or spamming 
 * use of the domain for spamming (affecting e-mail or other forms of electronic messaging) 

Where applicable, the policy includes metrics and thresholds for finding quantitative indications of malicious conduct.

Procedures to stop malicious activity may include (but are not limited to) : 
 * notifying the domainʹs sponsoring registrar, specifying a deadline until which the activity needs to be ceased, 
 * notifying the domainʹs registrant, administrative or technical contact directly (again specifying a deadline until which the activity needs to have ceased), 
 * locking the domain and putting it on hold in order to prevent changes to the domain and to remove it from the .PARIS zone (ʺtakedownʺ) 
 * deleting the domain name and blocking it from further registration if need be. Escalation rules (defining which steps are to be taken in which order and conditions for moving on to the next, more drastic measure) are part of the policy. 

Since removing a domain name from the .PARIS zone usually has serious consequences (such as rendering web sites and e-mail addresses utilizing the domain name unusable), the .PARIS Registry will, in accordance with the policy, exercise extreme caution with regard to any takedown decision. 

At the same time, the .PARIS Registry is aware that malicious activity potentially affects a large number of Internet users, which sometimes warrants drastic measures. The Rapid Takedown Policy aims at finding appropriate measures, taking the interests of all involved parties into consideration. The Rapid Takedown Policy will be announced to both .PARIS registrars and .PARIS registrants and be part of the Registry-Registrar Agreement (RRA) and the .PARIS registration terms. 


------------------------
2 - Rapid Takedown Policy for Cases of Phishing


The .PARIS Registry will work closely with French-based CERTs to develop an Anti-Phishing-specific simplified procedure. The goals will be to :
 * get all 7 French CERTs (at least, but open to other CERTs) accredited as Authorized Intervenors
 * develop criteria and checklist for domain names eligible for Rapid Suspension
 * develop secured communications method between Authorized Intervenor and Registry, including Affidavit form


Names reported by Authorized Intervenors will be suspended in less than 4 hours. This system should expand to a global Authorized Intervenors list. In this regard, the .PARIS Registry will work with the Antiphishing Working Group in order to develop and complete their proposed Accelerated Take Down proposal, which is still in beta stage.


------------------------
3 - Abuse Single Point of Contact 

To ensure that the .PARIS Registry gets notified of any cases of abuse as quickly and as easily as possible, an area of the public web site operated by the .PARIS Registry for the .PARIS TLD will be dedicated to the reporting of such cases.

 The respective web pages establish a single point of contact where abuse cases can be reported via a simple web form. An e-mail address and a phone number will also be provided as alternative means of communication. 

Every case reported will raise a high-priority ticket within the .PARIS support staffʹs ticket system, examined immediately and treated in accordance with the Rapid Takedown Policy (and the other Compliance Procedures related to Eligibility and Use, and IP Claims).
 

------------------------
4 - Prevention of Domain Name Tasting or Domain Name Front Running

The life cycle of a .PARIS domain name includes a 5-day Add Grace Period (AGP) during which a newly created domain name may be deleted with a refund of the domain fee. This is common practice and corresponds to the policies of almost all existing generic top level domains.

However, in the past the Add Grace Period has been abused for practices such as domain name tasting and domain name front running. 
Domain name tasting means that domains were created simply for the purpose of testing whether revenue can be generated by e.g. creating a web page with advertisements for the domain; if this was found feasible within the first few days, the domain was retained, otherwise it was deleted within the add grace period for a full refund, i.e. the domain was ʺtastedʺ for potential revenue without any payment to the registry. 
Domain name front running refers to the practice of pre-registering domain names somebody has merely expressed interest in (e.g. by searching for them on the Whois web frontend of a registrar) with the purpose of reselling the domain to that person (at an inflated price) afterwards; again, the Add Grace Period has been abused for this purpose since a registrar could do that without any cost (if the unsold domain was deleted before the end of the add grace period).

In 2008, ICANN introduced the so-called ʺAGP Limits Policyʺ (http:⁄⁄ www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) which addresses these and other issues resulting from the Add Grace Period. The .PARIS TLD, will fully implement this policy by restricting Add Grace Period refunds to registrars according to the limits specified by the policy. At the end of every month, the registration systemʹs billing module will determine every registrarʹs net domain adds and check whether the add grace period refunds granted during that month exceed the permissible number according to the policy; if this is the case, additional charges to the registrarʹs account will be initiated to effectively revert the excessive refunds.

Any exemption requests by registrars, whether they were granted (as permitted by the policy) or rejected, are documented, and such documentation will be maintained and made available for review by ICANN on request. The registryʹs monthly report to ICANN will contain per-registrar information on the granted add-deletes, as well as additional columns regarding the exemption requests.

The related report columns are (with column header names in parentheses):
 * number of AGP deletes (ʺdomains-deleted-graceʺ) 
 * number of exemption requests (ʺagp-exemption-requestsʺ) 
 * number of exemptions granted (ʺagp-exemptions-grantedʺ) 
 * number of names affected by granted exemption request (ʺagp- exempted-domainsʺ) 
 

------------------------
5 - Prevention of Domain Name Sniping (Grabbing)

Domain name sniping (also known as ʺgrabbingʺ) is another common abuse pattern; the name refers to the practice of trying to re-register potentially interesting domain names immediately after they are deleted (sometimes by accident, or because a registrant failed to renew the domain with his registrar in time).

Starting in 2002, registries have started to implement an ICANN proposal, the so-called ʺRedemption Grace Periodʺ (RGP, http:⁄⁄www.icann.org⁄en⁄registrars⁄redemption-proposal-14feb02.htm). The proposal recommends to introduce a 30-day period after a nameʹs deletion during which the name is removed from the TLD zone (in order to give the registrant the chance to take notice
of his nameʹs deletion) but is still eligible for being restored by the previous registrar⁄registrant. 

Supporting the RGP significantly reduces chances for domain grabbers to obtain inadvertently deleted domains, since a registrant gets 30 days to notice the mistake and restore the domain before it becomes available for re-registration.

The .PARIS 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)ʺ).


------------------------
6 - Prevention of Orphaned Glue Records

According to the definition found in the ʺSSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebookʺ (http:⁄⁄www.icann.org⁄en⁄ committees⁄security⁄sac048.pdf), a glue record becomes an ʺorphanʺ when the delegation point NS record (the ʺparent NS recordʺ) that references it 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 .PARIS TLD 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 by the following measures:

 * A host object within the .PARIS TLD (like e.g. ʺns.example.parisʺ) cannot exist without its parent domain (ʺexample.parisʺ). Any attempt to create the host ʺns.example.parisʺ will be rejected by the SRS if the domain ʺexample.parisʺ doesnʹt already exist or isnʹt sponsored by the registrar creating the host. Likewise, the domain ʺexample.parisʺ cannot be deleted by the registrar if subordinate hosts like ʺns.example.parisʺ still exist. These subordinate hosts have to be deleted before the domain may be deleted; if such hosts are used in delegations for other .PARIS names, these delegations in turn have to be removed before the host may be deleted.
 * If a domain name is put on hold (e.g. as a consequence of the Rapid Takedown Policy described above), this not only means that the delegation for the name itself is removed from the zone; it also means that any occurrences of NS records referencing a name server that is subordinate to the domain are also removed from other .PARIS domains, along with any accompanying glue records. The same of course holds true should the domain name have to be deleted entirely by the registry.

Consequently, no glue records can exist for a certain domain in the .PARIS zone after that domain is put on hold or deleted as part of abuse prevention or mitigation procedures.

It should be noted that this policy may lead to other domains (not directly involved in the abuse case) being affected by the takedown if they were delegated to a name server subordinate to the offending domain. Depending on their overall DNS architecture, such domains may become unreachable or less reachable after the delegation point is removed. While this could in theory be avoided by a less rigid orphan glue record policy, the overall benefit of adopting the strict policy described above is deemed higher than the potential damage to domains using an DNS infrastructure depending on an offending domain name.


------------------------
7 - Preventing Use of Reserved, Invalid, Illegal or Otherwise Unsuitable .PARIS Names

As laid out in the answer to Question 29 (Rights Protection Mechanisms), the .PARIS Registry takes extensive measures to protect the legal rights of others (such as trademark holders) with regard to .PARIS domain names. 

In addition, the .PARIS Shared Registration System (SRS) provides general means to make sure that no .PARIS names are registered which are for other reasons deemed invalid, reserved, illegal, offensive or unsuitable.

 ------------------------
 7.1 - Rule Engine

For the most part, this is achieved by the deployment of a complex rule engine that checks each registered name at the time of registration for compliance with a configurable set of rules. Among other things, these rules will include :
 * 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 disallow reserved geopolitical names 
 * a test to disallow registry reserved names 
 * a test to disallow ICANN reserved names 
 * a test to disallow otherwise reserved or unsuitable names 

For the tests checking for reserved names, custom lists of labels can be conveniently maintained by the registry to define the disallowed names for each category. 

 ------------------------
 7.2 - Pattern matching and fuzzy string comparison 

In addition to the pre-registration checks described above, the rule engine also supports testing registered domain names against a set of configurable string patterns, as well as for their similarity to a set of disallowed strings. 

------------------------
8 - Domain Data Access Control 

One important point of attack that may lead to abuse of .PARIS domains and their associated data is the unauthorized or excessive access to data stored within the .PARIS repository. This applies to both read access (e.g. via public interfaces such as the port 43⁄port 80 Whois) and write access (such as registrar interfaces like EPP or the web-based Control Panel or Extranet). The measures taken in the .PARIS TLD to properly restrict access are laid out in the following sub-sections.

 ------------------------
 8.1 - Prevention of Whois Data Mining

The port 43⁄port 80 Whois interfaces grant public access to domain, host and contact data. As such they are a potential target for data mining, i.e. the retrieval of large amounts of postal or e-mail addresses for e.g. the purpose of advertising.

As explained in detail in the answer to question 26 (Whois), the Whois implementation provided by the .PARIS Registration System prevents such data mining attempts, most importantly by :
 * rate-limiting access to all Whois interfaces (for machines not whitelisted for unlimited access), 
 * requiring web interface users to pass a CAPTCHA before access is granted and 
 * providing full support for global contact disclosure flags as specified in RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, giving registrants control over the contact fields they want to disclose in the Whois. In this respect, the system is configurable and allows restricting the use of EPP contact disclosure settings via rules defined by specific registry policies or legal requirements. 

 ------------------------
 8.2 - Prevention of Unauthorized Data Modifications

Domain data within the .PARIS Registry is exclusively provisioned by registrars, i.e. registrants have no direct write access to their data within the repository; all their modifications have to be done via the registrar sponsoring the respective domain. In this constellation, registrants needs to trust their registrar and will expect that the management of domain is conducted in a diligent and correct manner. This means that the registryʹs interfaces used by registrars need to be secured in order to only allow the sponsoring registrar of a domain (and nobody else) to modify domain data. 

The EPP interface provided by the .PARIS SRS does this by :
 * requiring SSL⁄TLS on the transport layer, 
 * requiring a strong EPP password (minimum length, mandatory digits and non-alphanumerical characters), 
 * requiring changing the EPP password on a regular basis, 
 * requiring registrars to supply lists of IP addresses or subnets from which exclusive access will be granted, 
 * requiring registrars to use SSL client certificates known to and trusted by the registry, thus providing an additional means of authentication beyond the EPP password.


Likewise, the web-based Control Panel (Extranet) :
 * requires SSL⁄TLS on the transport layer, 
 * requires registrars to log in with a user name and password (for which the same rules regarding minimum length, mandatory digits and non- alphanumerical characters apply), 
 * requires changing the password on a regular basis, 
 * requires registrars to supply lists of IP addresses or subnets from which exclusive access will be granted, 
 * requires registrars to install SSL client certificates known to and trusted by the registry in their web browsers, thus providing an additional means of authentication beyond the web password. 


------------------------
9 - Whois Accuracy 

Since .PARIS is operated as a so-called ʺthick registryʺ, the .PARIS Whois displays information about the registrant, as well as the administrative, technical and billing contacts of every .PARIS domain. In cases of malicious or abusive activity involving a .PARIS domain, this Whois contact information usually is the first and most important source of information, e.g. for law enforcement authorities, to determine the people or organizations responsible for the domain in a timely manner. Consequently, it is deemed very important to maximize the accuracy of contact information stored in the registry repository. 


The .PARIS Registry is therefore committed to take diligent measures to promote Whois accuracy, including (but not limited to) the following: 

 * Contact data completeness policy: While RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, merely requires contact data to contain a name, a city, a country code and an e-mail address for a syntactically complete EPP request, the .PARIS TLD policy for contact data mandates the specification of at least one address line (street), a voice phone number and a postal code in addition. This means that, in addition to the XML schema validation conducted by the .PARIS SRS for every EPP request received from the registrar (which ensures the presence of all RFC-mandated contact data), the SRS also requires these essential fields to be present and will reject requests lacking them with a ʺparameter value policy errorʺ message. The validation done by the SRS also goes beyond validating against the EPP XSDs with respect to field content. For instance, contact e-mail addresses are required to contain an ʹ@ʹ character and a valid domain name; this is not mandated by the XSDs specified in RFC 5733.

 * Domain data change notifications: The .PARIS Registration System can be configured (on a per-registrar basis) to automatically notify certain contacts of a domain (e.g. both the registrant and the administrative contact in order to reach multiple people concerned with the domain) after every change made to the domain (i.e. alterations of associated contacts or name servers). When enabled, this feature allows unauthorized or unintended changes to domain and contact data to be detected immediately. This functionality will however need to be deployed after consultation with .PARIS registrars, since many registrars do not endorse direct communication between the registry and registrants, i.e. their customers. 

 * Contact data monitoring: On a regular basis, the registry will run automated plausibility audits on the contact data submitted by registrars. Using publicly available databases, contact address lines will e.g. be mapped to cities and zip codes, which are then compared to the ones provided by the registrant. 

 * WDRP auditing: In 2003, ICANN adopted the so-called ʺ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 .PARIS Registry does not intend to replicate this reminder procedure on the registry level, it will establish an auditing process that monitors the WDRP activities of .PARIS registrars to make sure that WDRP responsibilities are honoured. 


------------------------
10 - Resources 

 ------------------------
 10.1 - Initial Implementation

Thanks to the experience and prior investment by its Registry Service Providers (AFNIC and CORE), the .PARIS Registry already supports the above mentioned technical abuse prevention and mitigation measures. No additional engineering is required for these, which means that no special development resources are needed. 

 ------------------------
 10.2 - Ongoing maintenance

As for ongoing operations when the TLD is launched, regular audits and permanent monitoring actions, as well as timely reactions to reports of malicious activity will be provided by specially trained support staff from The Registry Operator.

It is estimated that the ongoing maintenance of this function will require on average about 30 man. hours per month, or a total of 43 man.day per year. These resources will be committed in part by the Registry Operator - The City of Paris - in line with its Staffing projection as detailed in Question 47 (Costs), and by the Registry Service Providers - AFNIC and CORE.

Table of Contents

1 - Sunrise: Criteria; Conflict Resolution; Mechanisms
2 - Compliance Mechanisms. Ongoing Registrations
 2.1 - Ex-officio random checks
 2.2 - Complaints, Rights Protection.
3 - Dispute Resolution (and Prevention) Mechanisms involving Rights Protection
 3.1 - Compliance with ICANN-mandated Dispute Resolution Mechanisms
 3.2 - Additional compliance measures related to ICANN-mandated policies
 3.2.1 - UDRP
 3.2.2 - URS
 3.2.3 - TM Notifications
4 - Technical Implementation details
 4.1 - Sunrise
 4.1.1 - Sunrise EPP Extension Support
 4.1.2 - Sunrise Registration Life Cycle Support
 4.1.3 - Trademark Clearinghouse Support
 4.1.4 - Support for Multiple Applications for the Same Domain Name
 4.1.5 - Issue System
 4.2 - Trademark Claims
5 - Resourcing Plan
 5.1 - Initial Implementation
 5.2 - Ongoing maintenance



The .PARIS TLD is fully committed to preventing abusive uses of its namespace, regarding legal rights of third parties, and beyond. It is fully committed to an orderly namespace with clear and effective policies guaranteeing the domain names are used[a] according to the principles of the TLD by the relevant community, as explained in more detail in questions 18 and 20.


In this regard, this is an outline of the Enforcement Policies that have an effect on Rights Protection and which will be implemented under .PARIS. These policies aim to comply fully with and exceed Specification 7 of ICANN’s Registry Agreement.


------------------------
1 - Sunrise: Criteria; Conflict Resolution; Mechanisms


As explained in answers to questions 18 and 20, .PARIS Sunrise will consist of a long, orderly Sunrise period during which multiple applications will be accepted and published, and then validated, prioritized and eventually accepted or rejected according to their relative priority.


The Sunrise will have two main Categories, each one with different sub-categories:

 * Public Administrations (for public authorities with legal competences in the territory of .PARIS as defined, but also with a last-in-priority phase for other public administrations wishing to protect their names in .PARIS).

 * Trademarks, and other Distinctive Signs (with full compliance with the Trademark Clearinghouse process; also giving priority to Trademarks that have legal effect in the relevant territory for the .PARIS TLD, that is : TM registered in France at INPI, European TM registered with OHMI, and International TM in force in France according to the Madrid system).

Each application will be individually validated against both the general requirements of .PARIS registration policies and the specific requirements of each Category or Sub-Category. Priority will be differentiated by Category (and Sub-category) each one having absolute priority over the next one. 

Within each Category (and Sub-category) all validated applications will be deemed to carry the same rights. Auction will be the last resort resolution mechanisms for intra (sub-)category concurrent applications, but the party may avoid it by electing for Mediation.

When rejecting an application, the applicant will have one week to notify its intention to appeal the decision (before an independent Mediation and Arbitration Center). In that case, no application for the same name from the same or lower rank in Sunrise priority will be approved, pending the Appeal. If the Appeal decisions ruling that the Registry failed to apply the Sunrise Registration Policies in an adequate manner, will result in the restoration of the domain name which processing will then resume according to the Sunrise Registration Policies (within the category or lower priority categories) 

The registry will also offer the TM Claims mechanism as provided by the TM Clearinghouse. This service will be provided not just for the Sunrise period, but also afterwards, during the Ongoing Registration Phase.

Finally, we should underline that there is an additional Category running in parallel during the Sunrise: the No Priority Category, where applicants can apply for the name they wish and will only get it in case no one applies for it on any privileged category (as a “Landrush” mechanism, therefore).


------------------------
2 - Compliance Mechanisms. Ongoing Registrations

As explained in question 18 and 20, once in Ongoing (live) Registration mode, the .PARIS Registry will perform ex-post validation based on whois data and use of the domain name, both against the Registrations Policies and, when collected, the Intended Use Statement provided by the registrant[b]. 


 ------------------------
 2.1 - Ex-officio random checks

Checks will be performed by compliance agents both based on complaints and ex-officio, on statistically targeted random checks. Registry will start with 50 such random cases per day, and will adapt the practices according to the experience gained (it is expected that the number will decrease over time, as reputation and enforcement will make compliance easier over time).

Checks will be carried both on compliance with .PARIS policy and at the same time on registrant data accuracy. 

In case the compliance agents discover a problem, either on policy compliance or on data accuracy, they will escalate the issue to the Compliance Officers, and the registrant will be contacted to clarify⁄correct the situation. If not solved in due time (30 days), the name will be put on registry hold for 30 additional days. Unless the situation is corrected by this deadline, the name will be removed. 

 ------------------------
 2.2 - Complaints, Rights Protection. 

Similarly, in case of a third-party complaint for infringement of rights of others, the Compliance Officers will request the complainant to compile a specific form including such information as : 
 * identification of complainant, 
 * identification of right infringed, 
 * declaration of good faith belief that the domain name is used to violate said right, 
 * acceptance of jurisdiction of the Paris courts in case the name is blocked and the registrant wants to sue the complainant for damages.

Then the registrant will be contacted. In case it provides within the following 14 business days a counter-statement with some specific content (identification; signed declaration of non-infringement of rights, with explanation of reasons) the domain name will not be blocked, and the complainant shall use the URS, the UDRP, the .PARIS Eligibility and Registry Restrictions Dispute Resolution Procedure (ERDRP) or file a lawsuit in a competent court. In case the registrant fails to provide all the elements (which will often be the case in blatant violations) the domain name will be put on registry hold.

Against these decisions (not just for Rights Protections, but also in cases of Compliance decisions for Eligibility or use breaches or malicious conduct) the parties may appeal to an independent Mediation and Arbitration Authority according to .PARIS ERDRP.


------------------------
3 - Dispute Resolution (and Prevention) Mechanisms involving Rights Protection

 ------------------------
 3.1 - Compliance with ICANN-mandated Dispute Resolution Mechanisms

The .PARIS TLD will comply and agrees to adhere to any remedies ICANN imposes on RRDRP and PDDRP, as implemented and amended in the future.

.PARIS further agrees to implement UDRP and URS in the manner established in the .PARIS TLD Agreement and the Consensus Policies.

 ------------------------
 3.2 - Additional compliance measures related to ICANN-mandated policies

 ------------------------
 3.2.1 - UDRP

While compliance with the UDRP as it is now lies on registrars’ side, .PARIS is not willing to accept non-compliant registrars preventing its implementation. In addition to ICANN-applied sanctions, .PARIS will suspend the ability to register new domain names under .PARIS for those registrars failing to implement UDRP decisions. 

In order to do this, .PARIS will implement a specific complaints form for successful UDRP complainants facing non-cooperative registrars for .PARIS names. Upon evidence of non-compliance the offending registrar would be prevented from registering any new .PARIS name for three months after effective compliance the first time, and six months in case of repeated failures to comply. This measure is more effective and less harmful for the end users than termination, and will be included in the .PARIS RRA.

 ------------------------
 3.2.2 - URS

.PARIS will immediately comply with URS decisions upon notification from the URS Service provider, through its Compliance Team.

Furthermore, .PARIS will offer the successful complainant, if the names becomes available for registration at any given time, a Notification Service for any future attempt to register such a name. This service will be free of charge to the successful URS complainant.

 ------------------------
 3.2.3 - TM Notifications

As noted above, .PARIS intends to extend the TM Claims services beyond the mandatory Sunrise period, and into the Ongoing Registration phase.


------------------------
4 - Technical Implementation details

 ------------------------
 4.1 - Sunrise

The .PARIS Shared Registration System (SRS) fully supports the requirements of the above mentioned Sunrise policy and phases via features described in this section.

 ------------------------
 4.1.1 - Sunrise EPP Extension Support

The system supports an EPP extension for submission of trademark data along with domain applications during launch phases such as Sunrise. Please refer to the answer to question 25 (Extensible Provisioning Protocol) for more information about the extension.

 ------------------------
 4.1.2 - Trademark Clearinghouse Support

The .PARIS Shared Registration System (SRS) is prepared for accessing APIs of the Trademark Clearinghouse in order to validate the trademark information submitted by the registrar during Sunrise. In addition, the system also contains provisions to make use of the Trademark Clearinghouse APIs for providing a Trademark Claims Service as soon as .PARIS enters a period of general availability (see below for more information on this service).

Since Trademark Clearinghouse Service Providers have not been assigned by ICANN at the time of writing, the concrete technical specifications for these APIs are not yet known. While basic provisions have been made in the .PARIS Shared Registration System (SRS), the details will therefore have to be finalised once the Service Providers have been announced. As described below, respective developer resources are allocated to perform this task.

 ------------------------
 4.1.3 - Support for Multiple Applications for the Same Domain Name

The .PARIS Shared Registration System (SRS) is designed to maintain multiple domain objects representing the same domain name at a given point in time. This feature is required to store multiple applications for the same name during launch phases like Sunrise.

To distinguish between the various applications of the name in the database (as well as in external APIs), each application is assigned a unique domain ID. These domain IDs are returned to registrars in the responses to domain applications via EPP and may subsequently be used, among other things, to inquire an applicationʹs review status. Also, review results are reported back to registrars via poll messages carrying the unique domain ID. Registrars can utilize the ID to clearly associate results with their applications.

 ------------------------
 4.1.4 - Issue System

When manual review of Sunrise applications is required, this typically involves a specific support team workflow that, among other things, consists of
 * storing application data in a database,
 * making application data available to the support staff via a web interface back office tool (BO)
 * assigning the task of reviewing applications for a certain domain name to a specific support member (for the purpose of clear responsibilities),
 * having the application reviewed by the assigned person, who in the process may
 * request additional information or documentation from the registrant,
 * adds such documentation, as well as comments concerning the review, to the application,
 * make a decision about the applicationʹs outcome or
 * forward the task to a different support person with better insight or higher decision privileges (who may then make the final decision).

To support this workflow, the .PARIS Shared Registration System (SRS) is equipped with a built-in Issue System integrated in its Back-Office (BO) that offers registry personnel a convenient web interface to review domain name applications and approve or reject them accordingly.


= The Issue System =

 * offers an SSL-secured web interface accessible by .PARIS registry staff only;
 * allows searching for applications by various criteria (e.g. domain name or current workflow⁄approval state);
 * allows a registry support person to find newly submitted or otherwise unassigned applications and take responsibility for them;
 * offers a two-level review workflow that allows the delegation of preselection tasks to the first level support staff, after which a final decision - if still required - can be made by second level personnel;
 * conveniently displays all application details, including registrant information, the supplied trademark information, as well as the results of the verification of that trademark data with the Trademark Clearinghouse;
 * fully tracks and documents application status and history, allowing for a complete audit in case of legal inquiries and
 * is fully integrated with the registry backend, i.e. it automatically notifies the SRS about the reviewersʹ decisions and immediately activates the respective domain in case of an approval. The Issue System also triggers the creation of appropriate EPP poll message in order to keep registrars informed about the outcome of their applications.

Such an Issue System has been used on many occasions including the launch of puntCATʹs elaborate multi-phase Sunrise period in 2006, as well as the relaxation of registration restrictions in the .FR TLD, and proved on these occasions to be an invaluable tool for efficiently organizing a TLD roll-out process. 

The experience gathered from developing and operating the Issue System in that context helped to develop a second-generation version from which the .PARIS TLD will benefit.

 ------------------------
 4.2 - Trademark Claims

As stated above, beyond the requirements set forth by ICANN in Specification 7 of the Registry Agreement, the .PARIS Registry will implement a continuous Trademark Claims Service to ensure that even after Sunrise, registrants are notified whenever their registered domain name potentially violates a trademark holderʹs rights as stored in the Trademark Clearinghouse. Likewise, the service makes the trademark holder aware of any domain registrations that potentially infringe on his trademarks registered with the Trademark Clearinghouse.

For the purpose of implementing this service, the .PARIS SRS will interconnect with the API provided by the Trademark Clearinghouse Service Provider once its details are developed and publicized by ICANN.

When a match of a registered name is found via the API provided by the Trademark Clearinghouse, the Trademark Claims Service is supposed to provide clear notice to a prospective registrant of the scope of the mark holderʹs rights. The registrant will in turn be required to provide statement that
 * he received notification that the mark is included in the Trademark Clearinghouse,
 * he received and understood the notice and
 * his registration and use of the requested domain name will not infringe on the rights that are subject of the notice.

The registrant will be directed to the Trademark Clearinghouse Database information referenced in the Trademark Claims Notice to enhance understanding of the Trademark rights being claimed by the trademark holder. Also, if a domain name is registered in the Clearinghouse, the registry will, through an interface with the Clearinghouse, promptly notify the mark holders(s) of the registration after it becomes effective.


------------------------
5 - Resourcing Plan

 ------------------------
 5.1 - Initial Implementation

Thanks to the experience and prior investment by its Registry Service Providers (AFNIC and CORE), the .PARIS Registry already supports the above mentioned functions and their support systems.

One aspect to be considered for resource planning is the registry systemʹs connection to the Trademark Clearinghouse; since the involved API isnʹt 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.day on the development of this feature.

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

 ------------------------
 5.2 - Ongoing maintenance

The operation of the above mentioned mechanisms will be ensured by a team of highly experienced individuals with a distinct track record in handling dispute and managing TLDs in a manner that very significantly minimize conflict. These individuals have learned directly for launch management and dispute resolution around the .CAT and .FR TLDs.

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

Two phases need to be distinguished in terms of resourcing plan : 

 * for the first 6 month (duration of the sunrise period) we estimate that - exceptionally - 5 FTE will be needed, shared between the administrative and expert-level staff members, at a 5-to-2 ratio.

 * after the finalization of the sunrise and for the longer term ongoing operations of the TLD, we estimate that the management of rights protection will require no more than 1.5 FTE at a 2-to-1 ratio with respect to the level of expertise (administrative vs. expert staff). These resources will be committed in part by the Registry Operator - The City of Paris - in line with its Staffing projection as detailed in Question 47 (Costs), and by the Registry Service Providers - AFNIC and CORE.

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;
 * NOC staff 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).