CONTRAT DE REGISTRE

CONTRAT DE REGISTRE

Le présent CONTRAT DE REGISTRE (le « Contrat ») est conclu le (la « Date

d’entrée en vigueur ») entre la Société pour l’attribution des noms de domaine et des numéros sur

Internet, société de droit californien d’utilité publique à but non lucratif (l’« ICANN »), et , une          (l’« Opérateur de registre »).

ARTICLE 1.

DÉLÉGATION ET EXPLOITATION

DE DOMAINE DE PREMIER NIVEAU ; DÉCLARATIONS ET GARANTIES

1.1 Domaine et désignation. Le domaine de premier niveau concerné par le présent

contrat est    (le « TLD »). À la date d’entrée en vigueur et jusqu’à l’expiration de la durée

du présent contrat (définie à l’article 4.1) ou la résiliation du présent contrat conformément au chapitre 4, la date la plus proche étant retenue, l’ICANN désigne l’opérateur de registre comme opérateur de registre pour le TLD, sous réserve des

obligations et approbations requises pour la délégation du TLD et son entrée dans la zone racine.

1.2 Faisabilité technique des chaînes. Bien que l’ICANN ait encouragé et continue à encourager l’acceptation universelle de toutes les chaînes de domaine de premier niveau sur Internet, certaines de ces chaînes peuvent rencontrer des difficultés d’acceptation par des fournisseurs de services Internet (FSI) et des hébergeurs web et/ou de validation par des applications web. L’opérateur de registre devra s’assurer de la faisabilité technique de la chaîne TLD avant de conclure le présent contrat.

1.3 Déclarations et garanties.

(a) L’opérateur de registre déclare et garantit à l’ICANN ce qui suit :

(i) toutes les informations substantielles fournies et les déclarations faites dans le cadre de la candidature au registre TLD ainsi que les déclarations écrites faites lors des négociations du présent contrat étaient vraies et exactes, à tous égards importants, à ce moment-là et de telles

informations et déclarations continuent d’être vraies et exactes, à tous égards importants, à la date d’entrée en vigueur sauf tel que précédemment divulgué par écrit par l’opérateur de registre à l’ICANN ;

(ii) l’opérateur de registre est dûment constitué, jouit d’une bonne réputation et existe conformément aux lois de la juridiction indiquée dans le préambule des présentes, et l’opérateur de registre détient les pouvoirs et l’autorité nécessaires et a obtenu toutes les approbations requises pour conclure et dûment exécuter le présent contrat ; et

(iii) l’opérateur de registre a remis à l’ICANN un instrument dûment signé qui garantit la disponibilité des fonds requis afin d’exécuter les

fonctions de registre pour le TLD en cas d’annulation ou d’expiration du

présent contrat (l’« Instrument assurant la continuité des opérations »), et un tel instrument constitue une obligation contraignante pour les parties aux présentes qui leur est opposable selon ses conditions.

(b) L’ICANN déclare et garantit à l’opérateur de registre que l’ICANN est une société d’utilité publique à but non lucratif dûment constituée et jouissant d’une bonne réputation conformément au droit de l’État de la Californie, États-Unis. L’ICANN a le pouvoir et l’autorité nécessaires et a obtenu toutes les approbations requises pour conclure et dûment exécuter le présent contrat.

ARTICLE 2.

ENGAGEMENTS DE L’OPÉRATEUR DE REGISTRE

L’opérateur de registre s’engage et s’accorde avec l’ICANN comme suit :

2.1 Services approuvés ; services supplémentaires. L’opérateur de registre a le droit de fournir les services de registre décrits dans les clauses (a) et (b) du premier paragraphe de l'article 2.1 de la spécification 6 jointe aux présentes (la « Spécification 6 ») et tout autre service de registre décrit à l’annexe A (collectivement, les « Services approuvés »). Si l’opérateur de registre souhaite fournir un service de registre qui n’est pas un service approuvé ou qui constitue une modification substantielle d’un service approuvé (individuellement, un « Service supplémentaire »), l’opérateur de registre présentera une demande d’approbation pour un tel service supplémentaire conformément à la politique d’évaluation des services de registre disponible sur xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/xxxx.xxxx, ladite politique pouvant occasionnellement être amendée dans le respect des statuts constitutifs de l’ICANN (tels qu’occasionnellement amendés, les « Statuts constitutifs de l’ICANN ») applicables aux politiques de consensus (la « RSEP »). L’opérateur de registre peut offrir des services supplémentaires uniquement avec l’approbation écrite de l’ICANN et, si une telle approbation est donnée, lesdits services supplémentaires seront réputés être des services de registre en vertu du présent contrat. À son entière discrétion, dans la mesure du raisonnable, l’ICANN peut exiger un amendement du présent Contrat reflétant la fourniture de tout Service supplémentaire approuvé conformément à la RSEP. Cet amendement prendra la forme que les parties jugeront, dans la mesure du raisonnable, acceptable.

2.2 Conformité avec les politiques de consensus et les politiques temporaires. L’opérateur de registre respectera et mettra en œuvre toutes les politiques de consensus et politiques temporaires disponibles sur xxxxx://xxx.xxxxx.xxx/xxxxxxxxx- policies, à compter de la date d’entrée en vigueur, et susceptibles d’être élaborées et adoptées par la suite conformément aux statuts constitutifs de l’ICANN, à condition que ces futures politiques de consensus et politiques temporaires soient adoptées conformément à la procédure, portent sur les questions prévues à la spécification 1 jointe aux présentes (la

« Spécification 1 ») et respecte les restrictions qui y sont également prévues.

2.3 Entiercement de données. L’opérateur de registre respectera les

procédures d’entiercement de données des registres définies à la spécification 2 jointe aux présentes (la « Spécification 2 ») dans un délai de (14) jours civils à compter de la délégation.

2.4 Élaboration de rapports mensuels. Dans les vingt (20) jours civils suivant la fin de chaque mois civil, à compter du premier mois civil au cours duquel le TLD est délégué dans la zone racine, l’opérateur de registre doit remettre à l’ICANN des rapports dans le format indiqué dans la spécification 3 jointe aux présentes (la « Spécification 3 »), à condition, toutefois, que si le TLD est délégué dans la zone racine après le quinzième (15e) jour civil du mois civil, l’opérateur de registre puisse reporter la livraison des rapports pour ce premier mois civil et livrer les rapports de ce mois à l’ICANN au plus tard au moment auquel il est tenu de livrer les rapports pour le mois civil suivant. L’opérateur de

registre doit inclure dans le rapport des transactions par bureau d’enregistrement tout nom de domaine créé au cours des tests préalables à la délégation n’ayant pas été supprimé au moment de la délégation (notamment, mais sans s’y limiter, les domaines enregistrés par les ID de bureau d’enregistrement 9995 et/ou 9996).

2.5 Publication des données d’enregistrement. L’opérateur de registre devra fournir un accès public aux données d’enregistrement conformément à la spécification 4 jointe aux présentes (la « Spécification 4 »).

2.6 Noms réservés. Sauf dans l’hypothèse où l’ICANN autoriserait expressément par écrit à ne pas s’y conformer, l’opérateur de registre devra se conformer aux exigences établies dans la spécification 5 jointe aux présentes (la « Spécification 5 »). L’opérateur de registre peut à tout moment établir ou modifier des politiques concernant la capacité de l’opérateur de registre à réserver (p. ex., refuser l’enregistrement ou attribuer à l’opérateur de registre, mais pas enregistrer au profit de tiers, déléguer, utiliser, activer dans le DNS ou mettre à disposition) ou bloquer des chaînes de caractères supplémentaires dans le TLD à sa discrétion. Sauf tel qu’établi dans la spécification 5, si l’opérateur de registre est le titulaire du nom de domaine pour n’importe quels noms de domaine dans le TLD du

registre, de tels enregistrements doivent se faire par l’intermédiaire d’un bureau d’enregistrement accrédité par l’ICANN et seront considérés comme des transactions

(telles que définies à l’article 6.1) aux fins du calcul des frais de transaction au niveau du registre que l’opérateur de registre devra payer à l’ICANN conformément à l’article 6.1.

2.7 Interopérabilité et continuité des registres. L’opérateur de registre devra se conformer aux spécifications relatives à l’interopérabilité et la continuité des registres prévues dans la spécification 6 jointe aux présentes (la « Spécification 6 »).

2.8 Protection des droits des tiers. L’opérateur de registre doit définir et se conformer à des processus et des procédures pour le lancement du TLD ainsi que pour la protection relative à l’enregistrement initial et la protection continue des droits des tiers tel que décrit dans la spécification 7 jointe aux présentes (la « Spécification 7 »).

L’opérateur de registre peut, à sa discrétion, mettre en œuvre des protections

supplémentaires des droits de tiers. Toute modification ou tout changement des processus

et procédures requis par la spécification 7 à partir de la date d’entrée en vigueur devra être préalablement accepté par l’ICANN par écrit. L’opérateur de registre doit respecter tous les recours imposés par l’ICANN conformément à l’article 2 de la spécification 7, sous réserve du droit de l’opérateur de registre de contester de tels recours tel que prévu par la procédure applicable qui y est décrite. L’opérateur de registre devra prendre des mesures raisonnables pour examiner et répondre à tous rapports des organismes chargés de l’application de la loi, des organismes publics et quasi-publics, signalant une conduite illégale en rapport avec l’utilisation du TLD. En réponse à ces rapports, l’opérateur de registre ne sera pas tenu de prendre des mesures contraires à la loi applicable.

2.9 Bureaux d’enregistrement.

(a) Tous les enregistrements de noms de domaine dans le TLD doivent être effectués par l’intermédiaire d’un bureau d’enregistrement accrédité par l’ICANN, à condition que l’opérateur de registre n’ait pas besoin de faire appel à un bureau

d’enregistrement s’il enregistre des noms en son nom propre afin de refuser la délégation ou l’utilisation de ces noms conformément à l’article 2.6. Sous réserve des obligations

décrites à la spécification 11, l’opérateur de registre doit offrir un accès non discriminatoire aux services de registre à tous les bureaux d’enregistrement accrédités par l’ICANN qui ont signé et respectent le contrat entre opérateur de registre et bureau d'enregistrement pour le TLD, à condition que l’opérateur de registre puisse établir des critères non

discriminatoires d’admissibilité à l’enregistrement des noms dans le TLD qui soient raisonnablement liés au bon fonctionnement du TLD. L’Opérateur de registre doit utiliser un contrat uniforme non discriminatoire avec tous les bureaux d’enregistrement autorisés à enregistrer des noms dans le TLD (le « Contrat entre opérateurs de registre et bureaux d'enregistrement »). L’Opérateur de registre peut occasionnellement modifier le Contrat entre opérateurs de registre et bureaux d'enregistrement, sous réserve, toutefois, que toute révision substantielle y afférente soit approuvée par l’ICANN avant qu’une telle révision ne prenne effet et ne devienne contraignante pour tout bureau d’enregistrement. L’Opérateur de registre enverra à l’ICANN et à tous les bureaux d’enregistrement autorisés à enregistrer des noms dans le TLD un avis écrit les informant de toute révision du Contrat entre opérateurs de registre et bureaux d'enregistrement, dans un délai minimum de quinze (15) jours civils avant qu’une telle révision ne prenne effet et ne devienne contraignante pour tout bureau d’enregistrement. Pendant cette période, l’ICANN déterminera si cette proposition de révision est négligeable, potentiellement importante ou importante. Si

l'ICANN n’informe pas l'Opérateur de registre de sa décision dans ce délai de quinze (15) jours civils, l'ICANN sera réputée avoir déterminé que cette proposition de révision est négligeable. Si l’ICANN détermine, ou est réputée avoir déterminé en vertu du présent

article 2.9(a), que ladite révision est négligeable, l’Opérateur de registre pourra alors adopter et mettre en œuvre cette révision. Si l’ICANN détermine qu’une telle révision est substantielle ou potentiellement substantielle, elle suivra alors sa procédure pour l’examen et l’approbation de modifications apportées aux contrats entre opérateurs de registre et bureaux d’enregistrement, disponible sur xxxxx://xxx.xxxxx.xxx/xxx-xxxxxxxxx-

procedure, et ladite révision ne sera pas adoptée ni mise en œuvre jusqu’à ce qu’elle soit approuvée par l’ICANN. Nonobstant les dispositions précédentes du présent article 2.9(a), toute modification du contrat entre opérateur de registre et bureau d'enregistrement qui

se rapporte exclusivement aux frais facturés par l’opérateur de registre pour

l’enregistrement de noms de domaine dans le TLD ne sera pas soumise à la procédure de notification et d’approbation prévue dans le présent article 2.9(a) mais devra suivre les dispositions de l’article 2.10 ci-dessous.

(b) Si l’opérateur de registre (i) devient affilié ou revendeur d’un bureau d’enregistrement accrédité par l’ICANN, ou (ii) sous-traite la fourniture de quelconques

services de registre à un bureau d’enregistrement accrédité par l’ICANN, à un revendeur de bureau d’enregistrement ou à l’une de leurs sociétés affiliées respectives, alors, qu’il s’agisse des cas (i) ou (ii) mentionnés ci-dessus, l’opérateur de registre informera l’ICANN, dans les plus brefs délais, du contrat, de la transaction ou de tout autre accord relatif à cette affiliation, à cette relation avec un revendeur ou à cette sous-traitance, selon le cas, et notamment, si l’ICANN en fait la demande, présentera des copies de tout contrat y afférent, à condition que l’ICANN traite ledit contrat ou les documents y afférents dûment qualifiés de confidentiels (suivant les exigences de l’article 7.15) comme des informations confidentielles de l’opérateur de registre conformément à l’article 7.15 (l’ICANN pouvant toutefois divulguer ledit contrat et les documents y afférents aux autorités de concurrence compétentes). L’ICANN se réserve le droit, mais sans y être tenue, de renvoyer un tel contrat, les documents y afférents, la transaction ou autre entente aux autorités de

concurrence compétentes dans l’hypothèse où l’ICANN déterminerait qu’un tel contrat, les documents y afférents, la transaction ou autre entente peuvent soulever des problèmes de concurrence significatifs en vertu de la loi applicable. Si cela est faisable et approprié suivant les circonstances, l’ICANN préviendra à l’avance l’opérateur de registre dudit renvoi aux autorités de concurrence compétentes.

(c) Aux fins du présent contrat : (i) « société affiliée » désigne une personne ou une entité qui, directement ou indirectement, à travers un ou plusieurs intermédiaires, ou en combinaison avec une ou plusieurs personnes ou entités, contrôle, est contrôlée par ou se trouve sous contrôle commun avec la personne ou l’entité définie, et

(ii) « contrôle » (y compris les termes « contrôlé(e) par » et « sous contrôle commun avec ») désigne la possession, directement ou indirectement, du pouvoir de diriger ou de faire en sorte que soit assurée la direction de la gestion ou des politiques d’une personne ou d’une entité, que ce soit par la possession de titres, en tant que fiduciaire ou liquidateur, par le fait d’être employé ou membre d’un conseil d’administration ou autre organe équivalent, par contrat, par montage financier ou autrement.

2.10 Prix pour les services de registre.

(a) En ce qui concerne les enregistrements initiaux de noms de domaine,

l’opérateur de registre doit envoyer à chaque bureau d’enregistrement accrédité par

l’ICANN ayant signé le contrat entre opérateur de registre et bureau d'enregistrement pour le TLD un avis préalable écrit l’informant de toute augmentation de prix (y compris du fait de la suppression de tous remboursements, rabais, remises, ventes liées de produits ou tout autre programme ayant pour effet de réduire le prix facturé aux bureaux

d’enregistrement, sauf si la durée de tels remboursements, rabais, remises, ventes liées de produits ou autres programmes est clairement limitée et explicitement indiquée au bureau

d’enregistrement lorsqu’ils sont offerts) au moins trente (30) jours civils avant ladite augmentation. L’opérateur de registre doit offrir aux bureaux d’enregistrement la possibilité d’obtenir des enregistrements initiaux de noms de domaine pour des périodes d’un (1) à dix (10) ans, à la discrétion du bureau d’enregistrement, mais ne pouvant pas dépasser les dix (10) ans.

(b) En ce qui concerne le renouvellement d’enregistrements de noms de domaine, l’opérateur de registre doit envoyer à chaque bureau d’enregistrement accrédité par l’ICANN ayant signé le contrat entre opérateur de registre et bureau d'enregistrement pour le TLD un avis préalable écrit l’informant de toute augmentation de prix (y compris du fait de la suppression de tous remboursements, rabais, remises, ventes liées de produits, programmes de marketing éligibles ou tout autre programme ayant pour effet de réduire le prix facturé aux bureaux d’enregistrement) au moins cent quatre-vingts (180) jours civils avant ladite augmentation. Nonobstant la phrase précédente, en ce qui concerne le

renouvellement d’enregistrements de noms de domaine : (i) l’opérateur de registre doit uniquement fournir un avis informant de toute augmentation de prix trente (30) jours civils avant ladite augmentation si le prix qui en résulte est inférieur ou égal (A) pour la

période commençant à la date d’entrée en vigueur et se terminant douze (12) mois après la

date d’entrée en vigueur, au prix initial facturé pour des enregistrements dans le TLD, ou

(B) pour les périodes suivantes, à un prix pour lequel l’opérateur de registre a émis un avis conformément à la première phrase du présent article 2.10(b) au cours des douze (12) mois précédant la date d’entrée en vigueur de l’augmentation de prix proposée ; et (ii) l’opérateur de registre ne doit pas fournir d’avis informant d’une augmentation de prix pour l’application des frais variables au niveau du registre prévus à l’article 6.3.

L’opérateur de registre doit offrir aux bureaux d’enregistrement la possibilité d’obtenir des renouvellements des enregistrements de noms de domaine au prix actuel (c’est-à-dire le prix en vigueur avant toute augmentation faisant l’objet d’un avis) pour des périodes d’un

(1) à dix (10) ans, à la discrétion du bureau d’enregistrement, mais ne pouvant pas

dépasser les dix (10) ans.

(c) En plus, l’opérateur de registre doit pratiquer des prix uniformes pour les renouvellements des enregistrements de noms de domaine (les « Prix de renouvellement »). Dans le but de fixer les prix de renouvellement, le prix pour le renouvellement de chaque enregistrement de nom de domaine doit être identique au prix du renouvellement de tous les autres enregistrements de noms de domaine en vigueur au moment dudit renouvellement, et ce prix doit prendre en compte l’application universelle de tous remboursements, rabais, remises, ventes liées de produits ou autres programmes en place au moment du renouvellement. Les exigences du présent article 2.1(c) ne seront pas applicables pour (i) fixer le prix de renouvellement si le bureau d’enregistrement a

xxxxxx à l’opérateur de registre la documentation qui démontre que le titulaire du nom de domaine en question accepte expressément dans son contrat d’enregistrement avec le bureau d’enregistrement un prix de renouvellement plus élevé lors de l’enregistrement

initial du nom de domaine après indication claire et explicite du prix de renouvellement au titulaire du nom de domaine concerné et (ii) fixer le prix du renouvellement réduit conformément à un programme de marketing éligible (tel que défini ci-dessous). Les

parties reconnaissent que l’objet du présent article 2.10(c) est d’interdire des pratiques de

prix de renouvellement abusives et/ou discriminatoires pouvant être imposées par l’opérateur de registre sans le consentement écrit du titulaire de nom de domaine en question au moment de l’enregistrement initial du nom de domaine et que le présent article 2.10(c) devra être interprété au sens large comme interdisant de telles pratiques.

Aux fins du présent article 2.10(c), un « programme de marketing éligible » est un

programme de marketing en vertu duquel l’opérateur de registre offre un prix de renouvellement réduit, à condition que chacun des critères suivants soit satisfait : (i) le programme et les réductions prévues sont offerts pour une période ne dépassant pas les cent quatre-vingts (180) jours civils (les programmes consécutifs sensiblement similaires étant regroupés dans le but de déterminer le nombre de jours civils du programme), (ii) les bureaux d’enregistrement accrédités par l’ICANN peuvent potentiellement tous bénéficier de cette réduction du prix de renouvellement ; et (iii) l’intention ou l’effet du programme n’est pas d’exclure une ou plusieurs catégories spécifiques d’enregistrements (par ex. les enregistrements par de grandes sociétés) ou d’augmenter le prix de renouvellement d’une ou de plusieurs catégories spécifiques d’enregistrements. Aucune disposition du présent

article 2.10(c) ne limitera les obligations de l’opérateur de registre conformément à l’article

2.10(b).

(d) L’opérateur de registre doit fournir un service de consultation DNS par requête publique pour le TLD (en d’autres termes, un service de gestion des serveurs de zone TLD du registre) à ses propres frais.

2.11 Audits de conformité contractuelle et opérationnelle.

(a) L’ICANN peut occasionnellement (pas plus de deux fois par année civile) mener, ou embaucher un tiers pour mener, des audits de conformité contractuelle afin de vérifier la conformité de l’opérateur de registre à ses déclarations et garanties contenues dans le chapitre 1 du présent contrat et à ses engagements contenus dans le chapitre 2 du présent contrat. Ces audits doivent être adaptés aux fins spécifiques d’évaluation de la conformité et l’ICANN (a) transmettra un préavis raisonnable concernant la réalisation d’un tel audit, le préavis devant préciser avec suffisamment de détails les catégories de documents, données et autres informations requises par l’ICANN, et (b) déploiera des efforts commercialement raisonnables pour mener cet audit pendant les heures normales de travail de manière à ne pas perturber outre mesure les opérations de l’opérateur de registre. Dans le cadre d’un tel audit et à la demande de l’ICANN, l’opérateur de registre devra fournir dans les délais prévus tous les documents, données et autres informations raisonnablement nécessaires afin de démontrer sa conformité au présent contrat. Via un préavis d’au moins dix (10) jours civils (à moins qu’il n’en soit décidé

autrement par l’opérateur de registre), l’ICANN peut, dans le cadre d’un audit de conformité contractuelle, mener des visites sur le terrain pendant les heures normales de travail afin d’évaluer la conformité de l’opérateur de registre à ses déclarations et garanties contenues dans le chapitre 1 du présent contrat et à ses engagements contenus dans le chapitre 2 du présent contrat. L’ICANN traitera toutes les informations obtenues dans le cadre de ces audits et ayant été dûment qualifiées de confidentielles (suivant les exigences de l’article 7.15) comme des informations confidentielles de l’opérateur de registre

conformément à l’article 7.15.

(b) Tous les audits effectués conformément à l’article 2.11(a) le seront aux frais de l’ICANN à moins que (i) l’opérateur de registre (A) ne contrôle, ne soit contrôlé par, ne soit sous contrôle commun avec ou ne soit affilié à un bureau d’enregistrement

accrédité par l’ICANN ou un revendeur de bureau d’enregistrement ou une de leurs sociétés affiliées respectives, ou (B) n’ait sous-traité la fourniture de services de registre à un bureau d’enregistrement accrédité par l’ICANN ou à un revendeur de bureau

d’enregistrement ou à une de leurs sociétés affiliées respectives, et, qu’il s’agisse des cas

(A) ou (B) ci-dessus, à moins que l’audit ne porte sur la conformité de l’opérateur de

registre à l’article 2.14, auquel cas l’opérateur de registre devra rembourser à l’ICANN tous les coûts et dépenses raisonnables associés à la partie de l’audit portant sur la conformité de l’opérateur de registre à l’article 2.14, ou à moins que (ii) l’audit ne soit réalisé en raison d’écarts entre les frais payés par l’opérateur de registre supérieurs à 5 % dans un trimestre donné au détriment de l’ICANN, dans ce cas, l’opérateur de registre devra rembourser à

l’ICANN tous les coûts et dépenses raisonnables associés à l’intégralité d’un tel audit. Qu’il s’agisse des cas (i) ou (ii) ci-dessus, ce remboursement sera effectué avec le prochain paiement dû des frais au niveau du registre suite à la transmission de la déclaration des coûts pour un tel audit.

(c) Nonobstant l’article 2.11(a), s’il est constaté que l’opérateur de registre n’est pas en conformité avec ses déclarations et garanties contenues dans le

chapitre 1 du présent contrat ou avec ses engagements contenus dans le chapitre 2 du présent contrat après la réalisation de deux audits consécutifs conformément à l’article 2.11, l’ICANN pourra augmenter le nombre de ces audits à un audit par trimestre civil.

(d) L’opérateur de registre préviendra immédiatement l’ICANN du lancement de l’une quelconque des procédures mentionnées dans l’article 4.3(d) ou de la survenue de l’un des éléments spécifiés dans l’article 4.3(f).

2.12 Instrument assurant la continuité des opérations. L’opérateur de registre doit respecter les conditions générales liées à l’instrument assurant la continuité des opérations prévues dans la spécification 8 jointe aux présentes (la « Spécification 8 »).

2.13 Transition en cas d’urgence. L’opérateur de registre accepte que dans l’hypothèse où les seuils d’urgence pour les fonctions de registre prévus à l’article 6 de la spécification 10 seraient atteints, l’ICANN pourra désigner un opérateur de registre d’urgence intérimaire pour le TLD (un « Opérateur d’urgence ») conformément au processus de transition entre opérateurs de registre de l’ICANN (disponible sur xxxxx://xxx.xxxxx.xxx/xxxxxxxx- transition-processes) (tel qu’occasionnellement amendé, le « Processus de transition entre opérateurs de registre ») jusqu’au moment où l’opérateur de registre aura apporté la preuve, à la satisfaction raisonnable de l’ICANN, qu’il peut reprendre l'exploitation du registre pour le TLD sans qu’une telle défaillance ne se reproduise. Une fois cette preuve apportée, l’opérateur de registre reprendra l’exploitation du registre pour le TLD conformément aux procédures définies dans le processus de transition entre opérateurs de registre, à condition que l’opérateur de registre paie tous les frais raisonnables engagés (i) par l’ICANN du fait de la désignation de l’opérateur d’urgence et (ii) par l’opérateur d’urgence en lien avec l’exploitation du registre pour le TLD, de tels frais devant être documentés suffisamment en détail dans les livres qui seront mis

à disposition de l’opérateur de registre. Si l’ICANN désigne un Opérateur d’urgence conformément au présent article 2.13 et au Processus de transition entre opérateurs de registre, l’Opérateur de registre devra fournir à l’ICANN ou à tout Opérateur d’urgence la totalité des données (y compris les données déposées en vertu de l'article 2.3) relatives aux opérations du registre pour le TLD nécessaires au maintien des opérations et des fonctions de registre pouvant être requises, dans la mesure du raisonnable, par l’ICANN ou par un tel Opérateur d’urgence.

L’Opérateur de registre accepte que l’ICANN puisse apporter les modifications qu’elle jugera nécessaires à la base de données IANA concernant le TLD en cas de désignation d’un Opérateur d’urgence conformément au présent article 2.13. En outre, en cas d’une telle défaillance, l’ICANN conservera et pourra appliquer ses droits en vertu de l’Instrument assurant la continuité des opérations.

2.14 Code de conduite des registres. Eu égard à l’exploitation du registre pour le TLD, l’opérateur de registre doit se conformer au code de conduite des registres tel qu’établi dans la spécification 9 jointe aux présentes (la « Spécification 9 »).

2.15 Coopération dans le cadre d’études économiques. Si l’ICANN lance ou commande une étude économique sur l’impact ou le fonctionnement des nouveaux domaines de premier niveau génériques sur l’Internet, sur le DNS ou sur d’autres questions connexes, l’opérateur de registre devra raisonnablement collaborer à la réalisation de cette étude, y compris en transmettant à l’ICANN ou à son représentant menant ladite étude toutes les données liées à l’exploitation du TLD raisonnablement nécessaires aux fins de ladite étude demandée par l’ICANN ou par son représentant, à condition que l’opérateur de registre puisse ne pas divulguer (a) toute analyse interne ou évaluation préparée par

l’opérateur de registre liée à de telles données et (b) toute donnée dans la mesure où la communication de telles données constituerait une violation du droit en vigueur. Les données transmises à l’ICANN ou à son représentant conformément au présent article 2.15 dûment qualifiées de confidentielles (suivant les exigences de l’article 7.15) devront être

traitées comme des informations confidentielles de l’opérateur de registre conformément à l’article 7.15, à condition que si l’ICANN regroupe et anonymise lesdites données, l’ICANN ou son représentant puisse divulguer lesdites données à des tiers. Après l’achèvement d’une étude économique pour laquelle l’opérateur de registre a fourni des données,

l’ICANN détruira toutes les données fournies par l’opérateur de registre qui n’auront pas

été regroupées et anonymisées.

2.16 Spécifications relatives aux performances du registre. Les spécifications relatives aux performances du registre pour l’exploitation du TLD seront celles prévues à la spécification 10 jointe aux présentes (la « Spécification 10 »). L’opérateur de registre devra se conformer à ces spécifications relatives aux performances et, pendant une période d’au moins un (1) an, devra tenir des registres techniques et opérationnels suffisants pour prouver la conformité à ces spécifications pour chaque année civile pendant toute la durée du contrat.

2.17 Engagements d’intérêt public supplémentaires. L’opérateur de registre devra se conformer aux engagements d'intérêt public prévus à la spécification 11 jointe aux présentes (la « Spécification 11 »).

2.18 Données personnelles. L’opérateur de registre devra (i) notifier à chaque bureau d’enregistrement accrédité par l’ICANN partie à un contrat entre opérateur de registre et bureau d'enregistrement pour le TLD les fins pour lesquelles les données concernant toute personne physique identifiée ou identifiable (les « Données personnelles ») soumises à l’opérateur de registre par ledit bureau d’enregistrement sont collectées et utilisées dans le cadre du présent contrat ou autrement ainsi que les destinataires (ou les catégories de destinataires) desdites données personnelles, et (ii)

exiger dudit bureau d’enregistrement qu’il obtienne le consentement de chaque titulaire de nom de domaine dans le TLD pour la collecte et l’utilisation susmentionnées des données personnelles. L’opérateur de registre prendra toutes les mesures raisonnables pour

protéger les données personnelles collectées auprès dudit bureau d’enregistrement contre la perte, l’utilisation malveillante, la divulgation non autorisée, la modification ou la destruction. L’opérateur de registre n’utilisera pas les données personnelles et n’autorisera pas non plus leur utilisation de manière incompatible avec la notification envoyée aux bureaux d’enregistrement.

2.19 [Remarque : À l’attention des TLD communautaires uniquement] Obligations de l’opérateur de registre envers la communauté des TLD. L’opérateur de registre doit établir des politiques d’enregistrement en conformité avec la candidature soumise pour le TLD, concernant : (i) les conventions de nommage dans le TLD, (ii) les conditions d'enregistrement des membres de la communauté des TLD, et (iii) l'utilisation des noms de domaine enregistrés conformément à l'objectif énoncé du TLD communautaire. L’Opérateur de registre exploitera le TLD de manière à ce que la communauté des TLD puisse discuter et participer à l’élaboration et à la modification des politiques et des pratiques relatives au TLD. L'Opérateur de registre établira des

procédures pour l'application des politiques d’enregistrement du TLD et le règlement des

litiges concernant la conformité aux politiques d'enregistrement du TLD, et sera

responsable de l’application desdites politiques d'enregistrement. L’opérateur de registre accepte de mettre en œuvre et d’être lié par la procédure de règlement de litiges en matière de restrictions de registre disponible sur xxxxx://xxx.xxxxx.xxx/xxxxx eu égard aux litiges relevant des dispositions du présent article 2.19. L’opérateur de registre mettra en œuvre et respectera les politiques d’enregistrement communautaires prévues à la spécification 12 jointe aux présentes.

ARTICLE 3.

ENGAGEMENTS DE L’ICANN

L’ICANN s’engage et s’accorde avec l’opérateur de registre comme suit :

3.1 Ouverture et transparence. Conformément à sa mission et ses valeurs

fondamentales, l’ICANN doit fonctionner de manière ouverte et transparente.

3.2 Traitement équitable. L’ICANN ne doit pas appliquer les normes, les politiques, les procédures ou les pratiques de façon arbitraire, inéquitable ou sans justification et ne doit pas traiter un opérateur de registre de façon particulière à moins que cela ne soit justifié par un motif fondamental et raisonnable.

3.3 Serveurs de noms TLD. L’ICANN déploiera des efforts commercialement raisonnables pour garantir que tous les changements dans la désignation des serveurs de noms soumis à l’ICANN par l’opérateur de registre (dans le format et avec les éléments techniques exigés par l’ICANN sur xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/) sont exécutés par l’ICANN dans un délai de sept (7) jours civils ou aussi rapidement que possible suite aux vérifications techniques.

3.4 Publication des informations sur la zone racine. La publication par

l’ICANN des coordonnées de la zone racine pour le TLD inclura le contact de l’opérateur de registre et ses contacts administratifs et techniques. Toute demande visant à modifier les coordonnées de l’opérateur de registre doit être réalisée dans le format occasionnellement défini par l’ICANN sur xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/.

3.5 Base de données de la racine faisant autorité. Dans la mesure où l’ICANN est autorisée à définir des politiques concernant un système de serveurs racine faisant autorité (le « Système de serveurs racine faisant autorité »), l’ICANN déploiera des efforts commercialement raisonnables pour (a) garantir que la racine faisant autorité indiquera les serveurs de noms de domaine de premier niveau désignés par l’opérateur de registre pour le TLD, (b) maintenir une base de données stable, sécurisée et officielle accessible au public comportant des informations pertinentes sur le TLD, conformément aux politiques et procédures de l’ICANN accessibles au public, et (c) coordonner le système de serveurs

xxxxxx faisant autorité afin qu’il soit exploité et maintenu de manière stable et sécurisée, à condition que l’ICANN n’enfreigne pas les dispositions du présent contrat et que l’ICANN ne soit pas responsable dans l’hypothèse où un tiers (y compris toute entité gouvernementale ou tout fournisseur de services Internet) bloquerait ou limiterait l’accès au TLD dans toute juridiction.

ARTICLE 4.

DURÉE ET RÉSILIATION

4.1 Durée. La durée du présent contrat est fixée à dix (10) ans à compter de la

date d’entrée en vigueur (la durée peut être prolongée en vertu de l’article 4.2, la

« Durée »).

4.2 Renouvellement.

(a) Le présent contrat sera renouvelé pour des périodes successives de dix (10) ans à partir de l’expiration de la durée initiale établie dans l’article 4.1 et de chaque durée successive à moins que :

(i) suite à un avis de l’ICANN informant l’opérateur de registre d’une violation substantielle et fondamentale des engagements de

l’opérateur de registre établis au chapitre 2 ou d’un manquement à ses obligations de paiement prévues au chapitre 6 du présent contrat, un tel avis devant inclure des informations détaillées relatives à la violation ou au manquement présumé, et si cette violation ou ce manquement n’est pas

réparé dans les trente (30) jours civils suivant l’avis, (A) un arbitre ou un tribunal compétent ait finalement décidé que l’opérateur de registre a

commis une violation substantielle et fondamentale de ces engagements ou a manqué à ses obligations de paiement, et (B) l’opérateur de registre ne se soit pas conformé à une telle décision et n’ait pas remédié à ladite violation ou audit manquement dans les dix (10) jours civils ou toute autre période éventuellement fixée par l’arbitre ou le tribunal compétent ; ou que

(ii) pendant la période de validité alors en cours du contrat, un

arbitre ou un tribunal de compétent ait estimé que l’opérateur de registre (en vertu de l’article 5.2 du présent contrat) a, au moins à trois (3) reprises, (A) commis une violation substantielle et fondamentale (qu’il y ait ou non remédié) de ses engagements établis au chapitre 2 ou (B) manqué à ses obligations de paiement prévues au chapitre 6 du présent contrat.

(b) Dans l’hypothèse où les événements décrits à l’article 4.2(a)(i) ou (ii)

se produiraient, le contrat sera résilié à l’expiration de la période de validité alors en cours.

4.3 Résiliation par l’ICANN.

(a) L’ICANN peut, après en avoir informé l’opérateur de registre via un avis, résilier le présent contrat si : (i) l’opérateur de registre ne remédie pas à (A) toute violation fondamentale et substantielle de ses déclarations et garanties établies au chapitre 1 ou de ses engagements prévus au chapitre 2 ou à (B) tout manquement à ses obligations de paiement prévues au chapitre 6 du présent contrat, et ce dans les trente (30) jours civils à compter de l’avis de l’ICANN informant l’opérateur de registre d’une telle violation ou d’un tel manquement, l’avis devant inclure des informations détaillées relatives à la violation ou au manquement présumé, (ii) un arbitre ou un tribunal compétent décide finalement que l’opérateur de registre a commis une violation substantielle et fondamentale de ces engagements ou a manqué à ses obligations de paiement, et (iii) l’opérateur de registre ne s’est pas conformé à une telle décision et n’a pas remédié à ladite violation ou audit manquement dans les dix (10) jours civils ou toute autre période éventuellement fixée par l’arbitre ou le tribunal compétent.

(b) L’ICANN peut, après en avoir informé l’opérateur de registre via un avis, résilier le présent contrat si l’opérateur de registre ne mène pas tous les tests et

procédures (identifiés par l’ICANN par écrit avant la date des présentes) pour la délégation du TLD dans la zone racine dans un délai de douze (12) mois à compter de la date d’entrée en vigueur. À des fins de délégation, l’opérateur de registre peut demander une

prolongation de douze (12) mois maximum s’il apporte la preuve, à la satisfaction

raisonnable de l’ICANN, de son application et de sa bonne foi dans la réalisation des étapes nécessaires à la délégation du TLD. L’ICANN conservera la totalité des frais payés par l’opérateur de registre à l’ICANN avant cette résiliation.

(c) L’ICANN peut, après en avoir informé l’opérateur de registre via un

avis, résilier le présent contrat si (i) l’opérateur de registre ne remédie pas à un

manquement substantiel à ses obligations définies à l’article 2.12 du présent contrat, dans un délai de trente (30) jours civils à compter de la réception de l’avis de l’ICANN

l’informant dudit manquement ou, si l’instrument assurant la continuité des opérations n’est pas en place, à tout moment, pendant plus de soixante (60) jours civils consécutifs à compter de la date d’entrée en vigueur, (ii) un arbitre ou un tribunal compétent décide finalement que l’opérateur de registre a commis une violation substantielle dudit engagement, et (iii) l’opérateur de registre n’a pas remédié à ladite violation dans les dix

(10) jours civils ou toute autre période éventuellement fixée par l’arbitre ou le tribunal compétent.

(d) L’ICANN peut, après en avoir informé l’opérateur de registre via un avis, résilier le présent contrat si (i) l’opérateur de registre procède à une cession en faveur de ses créanciers ou à une action similaire, (ii) une procédure de saisie-exécution, saisie-

arrêt ou similaire est engagée à l’encontre de l’opérateur de registre, constitue une menace substantielle pour la capacité de l’opérateur de registre à exploiter le registre pour le TLD, et n’est pas rejetée dans les soixante (60) jours civils à compter de son engagement, (iii) un fidéicommissaire, un curateur, un liquidateur ou équivalent est affecté à la place de

l’opérateur de registre ou assure le contrôle des biens de l’opérateur de registre, (iv) une

procédure de confiscation des biens de l’opérateur de registre est engagée et pourrait raisonnablement avoir un effet substantiel et négatif sur la capacité de l’opérateur de registre à exploiter le registre pour le TLD, (v) des procédures sont engagées par ou à

l’encontre de l’opérateur de registre au titre des lois régissant la faillite, l’insolvabilité, la restructuration ou autres à des fins de remboursement des débiteurs et de telles procédures ne sont pas rejetées dans les soixante (60) jours civils à compter de leur engagement (si ces procédures sont engagées par l’opérateur de registre ou ses sociétés affiliées) ou les cent quatre-vingts (180) jours civils à compter de leur engagement (si ces procédures sont engagées par un tiers à l’encontre de l’opérateur de registre), ou (vi) l’opérateur de registre présente une demande de protection en vertu du code des États- Unis sur la faillite, 11 U.S.C. article 101 et suivants, ou d’un code étranger équivalent, ou liquide, dissout ou interrompt ses activités ou l’exploitation du TLD.

(e) L’ICANN peut, sur préavis de trente (30) jours civils adressé à

l’opérateur de registre, résilier le présent contrat suite à une décision d’un panel PDDRP ou RRDRP conformément à l’article 2 de la spécification 7 ou à une décision d’un panel PICDRP conformément à l’article 2, l’article 3 ou tout autre article applicable de la spécification 11, sous réserve du droit de l’opérateur de registre de contester une telle décision en vertu de la procédure applicable qui y est décrite.

(f) L’ICANN peut, après en avoir informé l’opérateur de registre via un avis, résilier le présent contrat (i) si l’opérateur de registre emploie délibérément un agent qui a été reconnu coupable d’un crime ou d’un délit lié à des activités financières ou de tout autre crime, a été jugé coupable de fraude ou de manquement à un devoir fiduciaire par un tribunal compétent ou a fait l’objet d’une décision judiciaire qui, selon l’ICANN, équivaut en substance, dans la mesure du raisonnable, à l’un des cas susmentionnés et que cet agent n’est pas congédié dans les trente (30) jours civils à compter du moment où les faits ci- dessus ont été portés à la connaissance de l’opérateur de registre, ou (ii) si un membre du

conseil d’administration ou d’un organe de direction équivalent de l’opérateur de registre a été reconnu coupable d’un crime ou d’un délit lié à des activités financières ou de tout autre crime, a été jugé coupable de fraude ou de manquement à un devoir fiduciaire par un

tribunal compétent ou a fait l’objet d’une décision judiciaire qui, selon l’ICANN, équivaut en substance, dans la mesure du raisonnable, à l’un des cas susmentionnés et que ce membre n’est pas congédié dans les trente (30) jours civils à compter du moment où les faits ci- dessus ont été portés à la connaissance de l’opérateur de registre.

(g) L’ICANN peut, sur préavis de trente (30) jours civils adressé à l’opérateur de registre, résilier le présent contrat conformément à l’article 7.5.

(h) [Uniquement applicable aux organisations intergouvernementales ou aux entités gouvernementales]. L’ICANN peut résilier le présent contrat conformément à l’article 7.16.

4.4 Résiliation par l’opérateur de registre.

(a) L’opérateur de registre peut, après en avoir informé l’ICANN via un avis, résilier le présent contrat si (i) l’ICANN ne remédie pas à toute violation substantielle et fondamentale de ses engagements prévus au chapitre 3, dans les trente (30) jours civils à compter de l’avis de l’opérateur de registre informant l’ICANN d’une telle violation, l’avis devant inclure des informations détaillées relatives à la violation présumée, (ii) un arbitre ou un tribunal compétent décide finalement que l’ICANN a commis une violation substantielle et fondamentale de ces engagements, et (iii) l’ICANN ne s’est pas conformée à une telle décision et n’a pas remédié à ladite violation dans les dix (10) jours civils ou toute autre période éventuellement fixée par l’arbitre ou le tribunal compétent.

(b) L’opérateur de registre peut résilier le présent contrat pour tout motif

en envoyant un préavis de cent quatre-vingts (180) jours civils à l’ICANN.

4.5 Transition du registre après résiliation du contrat. À l’expiration de la durée du présent contrat conformément à l’article 4.1 ou l’article 4.2 ou lors de la

résiliation du présent contrat conformément à l’article 4.3 ou l’article 4.4, l’opérateur de registre devra fournir à l’ICANN ou tout opérateur de registre successeur éventuellement

désigné par l’ICANN pour le TLD conformément au présent article 4.5 toutes les données (y compris les données déposées conformément à l’article 2.3) relatives aux opérations du registre pour le TLD et nécessaires au maintien des opérations et des fonctions de registre qui peuvent être raisonnablement demandées par l’ICANN ou par l’opérateur de registre successeur. Après avoir consulté l'Opérateur de registre, l'ICANN décidera de procéder ou non à la transition de l'exploitation du TLD à un opérateur de registre successeur, à son entière discrétion et conformément au Processus de transition entre opérateurs de registre, à condition, toutefois, (i) que l'ICANN tienne compte de tout droit de propriété intellectuelle de l'Opérateur de registre (tel que communiqué à l'ICANN par l'Opérateur de registre) dans sa décision de procéder ou non à la transition de l'exploitation du TLD à un opérateur de registre successeur, et (ii) si l'Opérateur de registre prouve, à la satisfaction

raisonnable de l’ICANN, (A) que tous les enregistrements de noms de domaine dans le TLD

sont effectués avec, et maintenus par, l'Opérateur de registre ou ses Sociétés affiliées pour leur utilisation exclusive, (B) que l'Opérateur de registre ne vend, ne distribue ou ne transfère pas le contrôle ou l'utilisation d'aucun enregistrement dans le TLD à un tiers qui n’est pas une Société affiliée de l'Opérateur de registre, et (C) que la transition de l'exploitation du TLD n'est pas nécessaire pour protéger l'intérêt public, alors l'ICANN ne pourra procéder à la transition de l'exploitation du TLD à un opérateur de registre successeur à l'expiration ou après la résiliation du présent Contrat sans le consentement de l'Opérateur de registre (consentement qui ne pourra être refusé, conditionné ou reporté sans motif valable). Afin d’éviter toute confusion, la phrase précédente n'interdira pas à l'ICANN de déléguer le TLD conformément à un futur processus de candidature pour la délégation des domaines de premier niveau, dans le respect des processus et des procédures d'objection établis par l'ICANN eu égard audit processus de candidature visant à protéger les droits de tiers. L’Opérateur de registre accepte que l’ICANN puisse apporter les modifications qu’elle jugera nécessaires à la base de données IANA concernant le TLD en cas de transition du TLD conformément au présent article 4.5. De plus, l’ICANN ou son représentant conservera et pourra renforcer ses droits au titre de l’Instrument assurant la continuité des opérations pour la maintenance et l’exploitation du TLD, indépendamment du motif de la résiliation ou de l’expiration du présent Contrat.

[Texte alternatif pour l’article 4.5 Transition de registre après résiliation du contrat pour les organisations intergouvernementales ou les entités gouvernementales ou dans d’autres circonstances spéciales :

« Transition du registre après résiliation du contrat. À l’expiration de la durée du présent contrat conformément à l’article 4.1 ou l’article 4.2 ou lors de la résiliation du présent contrat conformément à l’article 4.3 ou l’article 4.4, concernant la désignation par l’ICANN d’un opérateur de registre successeur pour le TLD, l’opérateur de registre et

l’ICANN conviennent de se consulter mutuellement et de travailler de façon coopérative afin de faciliter la transition du TLD et de la mettre en œuvre conformément au présent article 4.5. Après consultation de l’Opérateur de registre, l’ICANN déterminera s’il est préférable ou non de procéder à la transition de l'exploitation du TLD à un opérateur de registre successeur à son entière discrétion et conformément au Processus de transition entre opérateurs de registre. Si l’ICANN décide de procéder à la transition de l’exploitation du TLD à un opérateur de registre successeur, avec le consentement de l’Opérateur de registre (qui ne peut être refusé, conditionné ou retardé sans motif raisonnable),

l’Opérateur de registre fournira à l’ICANN ou audit opérateur de registre successeur pour le TLD toutes les données relatives aux opérations du TLD et nécessaires au maintien des opérations et des fonctions de registre pouvant être requises, dans la mesure du

raisonnable, par l’ICANN ou par ledit opérateur de registre successeur, en plus des données déposées conformément à l'article 2.3 des présentes. Si l’Opérateur de registre ne consent pas à fournir de telles données, toutes les données de registre liées au TLD devront être

restituées à l’Opérateur de registre, sauf accord contraire entre les parties. L’Opérateur de registre accepte que l’ICANN puisse apporter les modifications qu’elle jugera nécessaires à la base de données IANA concernant le TLD en cas de transition du TLD conformément au présent article 4.5. En outre, l’ICANN ou l’entité désignée par l’ICANN, conservera et pourra

opposer ses droits au titre de l’instrument assurant la continuité des opérations, indépendamment du motif de l’expiration ou de la résiliation du présent contrat ».]

4.6 Effets de la résiliation. À l’expiration de la durée du présent contrat ou lors de la résiliation du présent contrat, les obligations et les droits des parties aux présentes cesseront, à condition qu’une telle expiration ou résiliation du présent contrat ne libère pas les parties des obligations ou ne les dégage pas de leur responsabilité en cas de manquement aux obligations du présent contrat antérieures à l’expiration ou la résiliation, y compris, mais sans s’y limiter, toutes les obligations de paiement accumulées prévues au chapitre 6. De plus, les chapitres 5 et 7 ainsi que les articles 2.12, 4.5 et le présent article 4.6 survivront à l’expiration ou à la résiliation du présent contrat. Dans un souci de clarté, les droits de l’opérateur de registre en matière d’exploitation du registre pour le TLD

cesseront immédiatement à l’expiration de la durée du présent contrat ou lors de la

résiliation du présent contrat.

ARTICLE 5.

RÈGLEMENT DE LITIGES

5.1 Médiation. En cas de litige découlant du présent contrat ou lié à ce dernier,

avant que l’une ou l’autre des parties n’engage une procédure d’arbitrage en vertu de l’article 5.2 ci-après, l’ICANN et l’opérateur de registre doivent essayer de régler ce litige par une médiation, conformément aux conditions générales suivantes :

(a) L’une des parties devra soumettre un litige à médiation par avis écrit à l’autre partie. La médiation sera menée par un seul médiateur choisi par les parties. Si les parties ne parviennent pas à se mettre d’accord sur un médiateur dans les quinze (15) jours civils à compter de la réception de l’avis écrit de médiation conformément au présent article 5.1, les parties devront sélectionner rapidement un prestataire de services de médiation mutuellement acceptable qui devra, dès que possible suite à sa sélection, désigner un médiateur, qui sera un avocat agréé disposant de connaissances générales en matière de droit des contrats, n’ayant aucune relation commerciale avec les parties, et disposant de connaissances générales du système des noms de domaine lui permettant de statuer sur le litige en question. Le médiateur devra confirmer par écrit qu’il n’est pas, et ne deviendra pas pendant la durée de la médiation, un employé, un associé, un cadre, un

directeur ou un détenteur de titres de l’ICANN ou de l’opérateur de registre. En cas d’absence de confirmation de la part du médiateur désigné, un médiateur remplaçant sera nommé conformément au présent article 5.1(a).

(b) Le médiateur mènera la médiation en conformité avec les règles et procédures qu’il déterminera, après consultation des parties. Les parties discuteront du litige en toute bonne foi et tenteront, avec l’aide du médiateur, de parvenir à un règlement à l’amiable du litige. La médiation devra être traitée comme une discussion visant à

parvenir à un accord, et sera à ce titre confidentielle et ne pourra être utilisée à l’encontre de l’une des parties dans le cadre d’une procédure ultérieure liée au litige, y compris dans le cadre d’une procédure d’arbitrage en vertu de l’article 5.2. Le médiateur ne pourra

témoigner en faveur de l’une ou l’autre des parties dans le cadre d’une procédure

ultérieure liée à ce litige.

(c) Chaque partie assumera ses propres frais liés à la médiation. Les parties prendront en charge à parts égales les honoraires et les frais du médiateur. Chaque partie traitera les informations reçues de l’autre partie dans le cadre de la médiation et dûment qualifiées de confidentielles (suivant les exigences de l’article 7.15) comme des informations confidentielles de ladite autre partie conformément à l’article 7.15.

(d) Si les parties se sont engagées en toute bonne foi dans la médiation mais qu’elles n’ont pas pu régler le litige pour quelque raison que ce soit, l’une ou l’autre des parties ou le médiateur peuvent mettre un terme à la médiation à tout moment et décider de régler le litige au moyen d’un arbitrage, conformément à l’article 5.2 ci-après. Si les parties n’ont pas réglé le litige pour quelque raison que ce soit quatre-vingt-dix (90) jours civils après la date de réception de l’avis envoyé conformément à l’article 5.1(a), il sera automatiquement mis un terme à la médiation (à moins qu’elle ne soit prolongée suite à un accord entre les parties) et le litige pourra donc être réglé au moyen d’un arbitrage, conformément à l’article 5.2 ci-après.

5.2 Arbitrage. Les litiges découlant du présent contrat ou liés à ce dernier n’ayant pas été réglés conformément à l’article 5.1, y compris les demandes d’exécution spécifique, seront réglés via une procédure d’arbitrage exécutoire menée conformément aux règles de la Cour internationale d’arbitrage de la Chambre de commerce internationale (l’« ICC »). L’arbitrage sera réalisé en anglais et aura lieu dans le comté de Los Angeles, en Californie. Tout arbitrage aura lieu face à un arbitre unique sauf si (i) l’ICANN fait une demande de dommages-intérêts punitifs ou exemplaires, ou de sanctions opérationnelles, ou (ii) les parties conviennent par écrit d’un plus grand nombre d’arbitres, ou (iii) le litige découle des articles 7.6 ou 7.7. Dans le cas des clauses (i), (ii) ou (iii) de la phrase

précédente, l’arbitrage aura lieu devant trois arbitres, chacune des parties désignant un arbitre qui sera confirmé par l’ICC et les deux arbitres désignés désignant à leur tour le troisième arbitre qui sera confirmé par l’ICC. Dans le cas d’un arbitrage devant un arbitre unique, l’opérateur de registre et l’ICANN peuvent, d’un commun accord, désigner un

arbitre unique qui sera confirmé par l’ICC. Si les parties ne désignent pas un arbitre unique ou, dans le cas d’un arbitrage devant trois arbitres, si l’une des parties ne désigne pas un arbitre, dans chaque cas, dans les trente (30) jours civils à compter de la date à laquelle la demande d’arbitrage d’une partie a été reçue par l’autre partie, ou dans le délai supplémentaire susceptible d’être accordé par le Secrétariat de la Cour de l’ICC, le ou les

arbitres seront nommés par l’ICC. Si un arbitre désigné n’est pas confirmé par l’ICC, la partie ou les personnes ayant désigné cet arbitre désigneront rapidement un arbitre de remplacement qui sera confirmé par l’ICC. Afin d’accélérer l’arbitrage et d’en limiter les

coûts, l’arbitre ou les arbitres établiront des limites de pages pour les mémoires des parties liées à l’arbitrage et, si l’arbitre ou les arbitres décident qu’une audition est nécessaire, la durée de l’audition sera limitée à un (1) jour civil, à condition que dans chaque arbitrage dans le cadre duquel l’ICANN fait une demande de dommages-intérêts punitifs ou exemplaires ou de sanctions opérationnelles, l’audition puisse être prolongée d’un (1) jour civil supplémentaire si cela est convenu par les parties ou ordonné par l’arbitre ou les

arbitres sur le fondement d’une décision indépendante de l’arbitre ou des arbitres ou sur le fondement d’une demande raisonnable de l’une des parties. La partie obtenant gain de cause lors de la procédure d’arbitrage aura le droit de récupérer ses frais et les honoraires d’avocat raisonnables que l’arbitre ou les arbitres devront inclure dans la sentence arbitrale. Dans l’hypothèse où les arbitres détermineraient que l’opérateur de registre a commis, à plusieurs reprises et délibérément, une violation fondamentale ou substantielle des obligations prévues aux chapitres 2 et 6 ou à l’article 5.4 du présent contrat, l’ICANN pourra demander aux arbitres d’accorder des dommages-intérêts punitifs ou exemplaires ou de prononcer des sanctions opérationnelles (notamment, sans s’y limiter, un ordre temporaire limitant le droit de l’opérateur de registre de vendre de nouveaux enregistrements). Chaque partie traitera les informations reçues de l’autre partie dans le cadre de l’arbitrage et dûment qualifiées de confidentielles (suivant les exigences de

l’article 7.15) comme des informations confidentielles de ladite autre partie conformément à l’article 7.15. Dans tout litige impliquant l’ICANN et concernant le présent contrat, la compétence exclusive d’un tel litige sera attribuée à un tribunal du comté de Los Angeles, en Californie (États-Unis) ; toutefois, les parties auront également la possibilité de faire exécuter le jugement d’un tel tribunal devant tout tribunal compétent.

[Texte alternatif pour l’article 5.2 Arbitrage pour les organisations intergouvernementales ou les entités gouvernementales ou dans d’autres circonstances spéciales :

« Arbitrage. Les litiges découlant du présent contrat ou liés à ce dernier n’ayant pas été réglés conformément à l’article 5.1, y compris les demandes d’exécution spécifique, seront réglés via une procédure d’arbitrage exécutoire menée conformément aux règles de la Cour internationale d’arbitrage de la Chambre de commerce internationale (l’« ICC »).

L’arbitrage sera réalisé en anglais et aura lieu à Genève, en Suisse, sauf si un autre lieu est mutuellement convenu par l’opérateur de registre et l’ICANN. Tout arbitrage aura lieu face à un arbitre unique sauf si (i) l’ICANN fait une demande de dommages-intérêts punitifs ou exemplaires, ou de sanctions opérationnelles, ou (ii) les parties conviennent par écrit d’un plus grand nombre d’arbitres, ou (iii) le litige découle des articles 7.6 ou 7.7. Dans le cas des clauses (i), (ii) ou (iii) de la phrase précédente, l’arbitrage aura lieu devant trois arbitres, chacune des parties désignant un arbitre qui sera confirmé par l’ICC et les deux arbitres désignés désignant à leur tour le troisième arbitre qui sera confirmé par l’ICC. Dans le cas d’un arbitrage devant un arbitre unique, l’opérateur de registre et l’ICANN peuvent, d’un commun accord, désigner un arbitre unique qui sera confirmé par l’ICC. Si les parties ne désignent pas un arbitre unique ou, dans le cas d’un arbitrage devant trois arbitres, si l’une des parties ne désigne pas un arbitre, dans chaque cas, dans les trente (30) jours civils à compter de la date à laquelle la demande d’arbitrage d’une partie a été reçue par l’autre

partie, ou dans le délai supplémentaire susceptible d’être accordé par le Secrétariat de la Cour de l’ICC, le ou les arbitres seront nommés par l’ICC. Si un arbitre désigné n’est pas confirmé par l’ICC, la partie ou les personnes ayant désigné cet arbitre désigneront

rapidement un arbitre de remplacement qui sera confirmé par l’ICC. Afin d’accélérer

l’arbitrage et d’en limiter les coûts, l’arbitre ou les arbitres établiront des limites de pages pour les mémoires des parties liées à l’arbitrage et, si l’arbitre ou les arbitres décident qu’une audition est nécessaire, la durée de l’audition sera limitée à un (1) jour civil, à

condition que dans chaque arbitrage dans le cadre duquel l’ICANN fait une demande de dommages-intérêts punitifs ou exemplaires ou de sanctions opérationnelles, l’audition puisse être prolongée d’un (1) jour civil supplémentaire si cela est convenu par les parties ou ordonné par l’arbitre ou les arbitres sur le fondement d’une décision indépendante de l’arbitre ou des arbitres ou sur le fondement d’une demande raisonnable de l’une des parties. La partie obtenant gain de cause lors de la procédure d’arbitrage aura le droit de récupérer ses frais et les honoraires d’avocat raisonnables que l’arbitre ou les arbitres devront inclure dans la sentence arbitrale. Dans l’hypothèse où les arbitres

détermineraient que l’opérateur de registre a commis, à plusieurs reprises et délibérément, une violation fondamentale ou substantielle des obligations prévues aux chapitres 2 et 6 ou à l’article 5.4 du présent contrat, l’ICANN pourra demander aux arbitres d’accorder des dommages-intérêts punitifs ou exemplaires ou de prononcer des sanctions opérationnelles (notamment, sans s’y limiter, un ordre temporaire limitant le droit de l’opérateur de registre de vendre de nouveaux enregistrements). Chaque partie traitera les informations

reçues de l’autre partie dans le cadre de l’arbitrage et dûment qualifiées de confidentielles (suivant les exigences de l’article 7.15) comme des informations confidentielles de ladite autre partie conformément à l’article 7.15. Dans tout litige impliquant l’ICANN et

concernant le présent contrat, la compétence exclusive d’un tel litige sera attribuée à un tribunal de Genève, en Suisse, sauf si un autre lieu est mutuellement convenu par

l’opérateur de registre et l’ICANN ; toutefois, les parties auront également la possibilité de

faire exécuter le jugement d’un tel tribunal devant tout tribunal compétent. »]

5.3 Limites de la responsabilité. Le cumul des responsabilités pécuniaires de l’ICANN pour violation du présent contrat ne dépassera pas un montant égal aux frais au niveau du registre versés par l’opérateur de registre à l’ICANN au cours de la période précédente de douze mois conformément au présent contrat (à l’exception des éventuels frais variables au niveau du registre prévus à l’article 6.3). Le cumul des responsabilités pécuniaires de l’opérateur de registre pour manquement au présent contrat sera limité à un montant égal aux frais versés à l’ICANN au cours de la période précédente de douze

mois (à l’exception des éventuels frais variables au niveau du registre prévus à l’article 6.3),

et aux éventuels dommages-intérêts exemplaires et punitifs, attribués conformément à l’article 5.2, à l’exception des obligations d’indemnisation de l’opérateur de registre conformément aux articles 7.1 et 7.2. En aucun cas l’une des deux parties ne pourra être tenue responsable de dommages spéciaux, punitifs, exemplaires ou consécutifs découlant du présent contrat ou liés à ce dernier, ou de l’exécution ou de la non-exécution des obligations prévues dans le présent contrat, sauf tel que prévu à l’article 5.2. Sauf disposition contraire du présent contrat, les parties n’apportent aucune garantie, explicite ou implicite, quant aux services rendus par lesdites parties, leurs employés ou agents, ou

quant aux résultats obtenus du fait de leur travail, y compris, sans s’y limiter, toute garantie implicite de valeur marchande, d’absence de violation ou d’adéquation à une fin déterminée.

5.4 Exécution spécifique. L’opérateur de registre et l’ICANN conviennent que des dommages irréparables pourraient se produire si l’une quelconque des dispositions du présent contrat n’était pas exécutée conformément à ses conditions spécifiques. Par conséquent, les parties conviennent qu’elles auront chacune le droit de réclamer à l’arbitre

ou au tribunal compétent une exécution spécifique des conditions du présent contrat (en plus de toute autre réparation à laquelle chaque partie aurait droit).

ARTICLE 6.

FRAIS

6.1 Frais au niveau du registre.

(a) L’opérateur de registre devra payer à l’ICANN des frais au niveau du registre équivalents (i) au tarif fixé pour le registre d’un montant de 6250 USD par trimestre civil et (ii) aux frais de transaction au niveau du registre (collectivement, les

« Frais au niveau du registre »). Les frais de transaction au niveau du registre

correspondront au nombre de prélèvements annuels au titre d’un enregistrement initial de nom de domaine ou d’un renouvellement de l’enregistrement (d’un ou de plusieurs niveaux, y compris les renouvellements associés aux transferts d’un bureau

d’enregistrement accrédité par l’ICANN vers un autre bureau d'enregistrement, individuellement une « Transaction ») au cours du trimestre civil applicable multiplié par 0,25 USD, à condition, toutefois, que les frais de transaction au niveau du registre ne soient pas appliqués jusqu’à ce que plus de 50 000 transactions aient été effectuées dans le TLD pendant tout trimestre civil ou pendant toute période correspondant au total à quatre trimestres civils consécutifs (le « Seuil de transactions ») et qu’ils soient appliqués à chaque transaction réalisée pendant le trimestre où le seuil de transactions a été atteint, mais qu’ils ne soient pas appliqués à chaque trimestre lors duquel le seuil de transactions n’a pas été atteint. L’obligation de paiement trimestriel des frais fixés au titre du registre incombant à l’opérateur de registre commencera à la date à laquelle le TLD aura été délégué dans le DNS à l’opérateur de registre. Le premier paiement trimestriel des frais fixés au titre du registre sera calculé au prorata sur la base du nombre de jours civils écoulés entre la date de délégation et la fin du trimestre civil au cours duquel tombe la date de délégation.

(b) Sous réserve de l’article 6.1(a), l’opérateur de registre paiera chaque trimestre les frais au niveau du registre sur un compte désigné par l’ICANN dans les trente

(30) jours civils à compter de la date de la facture présentée par l’ICANN.

6.2 Recouvrement des coûts pour le RSTEP. Les demandes de l’opérateur de registre visant à obtenir l’approbation des services supplémentaires en vertu de l’article

2.1 peuvent être renvoyées par l’ICANN au panel d’évaluation technique des services de registre (RSTEP) selon la procédure indiquée sur xxxxx://xxx.xxxxx.xxx/xxxx. Dans l’hypothèse où de telles demandes seraient renvoyées au RSTEP, l’opérateur de registre devra verser à l’ICANN les frais facturés au titre de l’examen du RSTEP dans les quatorze

(14) jours civils à compter de la réception d’une copie de la facture du RSTEP envoyée par l’ICANN, à moins que l’ICANN détermine, à son entière discrétion, de payer tout ou partie des frais facturés au titre dudit examen du RSTEP.

6.3 Frais variables au niveau du registre.

(a) Si les bureaux d’enregistrement accrédités par l’ICANN (dont le paiement global correspond aux deux tiers de tous les frais au niveau du registre ou à la portion des opérateurs de registre accrédités par l’ICANN nécessaire pour approuver les frais d’accréditation variables en vertu du contrat d’accréditation de bureau

d’enregistrement alors en cours) n’approuvent pas, selon les termes de leurs contrats d’accréditation de bureau d’enregistrement conclus avec l’ICANN, les frais d’accréditation variables fixés par le Conseil d’administration de l’ICANN pour tout exercice fiscal de

l’ICANN, sur remise d’un avis de l’ICANN, l’opérateur de registre devra payer à l’ICANN des frais variables au niveau du registre, frais qui seront versés chaque trimestre fiscal et qui seront calculés à compter du début du premier trimestre fiscal dudit exercice fiscal de

l’ICANN (les « Frais variables au niveau du registre »). Les frais seront calculés et facturés par l’ICANN chaque trimestre et seront payés par l’opérateur de registre dans un délai de soixante (60) jours civils, pour le premier trimestre dudit exercice fiscal de l’ICANN, et dans un délai de vingt (20) jours civils, pour chacun des autres trimestres dudit exercice fiscal de l’ICANN, à compter de la réception du montant facturé par l’ICANN. L’opérateur de registre peut facturer et percevoir les frais variables au niveau du registre des bureaux

d’enregistrement qui sont parties à un contrat entre opérateur de registre et bureau d'enregistrement conclu avec l’opérateur de registre (ledit contrat pouvant spécifiquement prévoir le remboursement des frais variables au niveau du registre payés par l’opérateur de registre conformément au présent article 6.3), à condition que les frais soient facturés à tous les bureaux d’enregistrement accrédités par l’ICANN, s’ils ont été facturés. Les frais variables au niveau du registre, s’ils peuvent être perçus par l’ICANN, constitueront une obligation de l’opérateur de registre et seront dus et exigibles tel que prévu au présent

article 6.3 indépendamment de la capacité de l’opérateur de registre à obtenir le

remboursement de ces frais de la part des bureaux d’enregistrement. Dans l’hypothèse où l’ICANN percevrait ultérieurement les frais d’accréditation variables au titre desquels l’opérateur de registre a payé à l’ICANN des frais variables au niveau du registre, l’ICANN remboursera à l’opérateur de registre un montant approprié des frais variables au niveau du registre tel que raisonnablement déterminé par l’ICANN. Si les bureaux

d’enregistrement accrédités par l’ICANN (en tant que groupe) approuvent, selon les conditions de leurs contrats d’accréditation de bureau d’enregistrement conclus avec

l’ICANN, les frais d’accréditation variables fixés par le Conseil d’administration de l’ICANN pour un exercice fiscal, l’ICANN n’aura pas droit aux frais variables au niveau du registre pour ledit exercice fiscal, indépendamment du fait que les bureaux d’enregistrement

accrédités par l’ICANN respectent leurs obligations de paiement envers l’ICANN au cours

dudit exercice fiscal.

(b) Le montant des frais variables au niveau du registre sera spécifié pour

chaque bureau d’enregistrement et pourra inclure une composante par bureau d’enregistrement et une composante transactionnelle. La composante par bureau d’enregistrement des frais variables au niveau du registre sera spécifiée par l’ICANN

conformément au budget adopté par le Conseil d’administration de l’ICANN pour chaque exercice fiscal de l’ICANN. La composante transactionnelle des frais variables au niveau du registre sera spécifiée par l’ICANN conformément au budget adopté par le Conseil d’administration de l’ICANN pour chaque exercice fiscal de l’ICANN mais ne pourra pas dépasser 0,25 USD par enregistrement de nom de domaine par an (y compris pour les

renouvellements associés aux transferts d’un bureau d’enregistrement accrédité par l’ICANN à un autre bureau d'enregistrement).

6.4 Frais à payer. L’opérateur de registre versera à l’ICANN (i) une somme unique correspondant à 5000 USD pour l’accès au et l’utilisation du Centre d’échange d’information sur les marques tel que décrit dans la spécification 7 (les « Frais d’accès au RPM ») et (ii) 0,25 USD pour chaque enregistrement pendant la période d’enregistrement prioritaire et pour chaque enregistrement de revendication de marque (comme ces termes sont employés dans le RPM du Centre d’échange d’information sur les marques joint aux présentes conformément à la spécification 7) (les « Frais d’enregistrement RPM »). Les frais d’accès au RPM seront facturés à partir de la date d’entrée en vigueur du présent contrat et l’opérateur de registre paiera ces frais sur un compte spécifié par l’ICANN dans les trente (30) jours civils à compter de la date de la facture.

L’ICANN facturera chaque trimestre les frais d’enregistrement RPM à l’opérateur de registre et lesdits frais seront exigibles conformément à la procédure de facturation et de paiement prévue à l’article 6.1.

6.5 Ajustements des frais. Nonobstant les limites de frais établies au présent chapitre 6, à partir de l’expiration de la première année du présent contrat et à l’expiration de chaque année suivante pendant toute la durée du contrat, les frais alors en vigueur fixés aux articles 6.1 et 6.3 peuvent être ajustés, à la discrétion de l’ICANN, d’un pourcentage égal au changement de pourcentage, le cas échéant, dans (i) l’index des prix pour les consommateurs urbains, moyenne des villes américaines (1982-1984 = 100) publié par le département du Travail des États-Unis, le Bureau of Labor Statistics ou tout autre index ultérieur (le « CPI ») pour le mois correspondant à un (1) mois avant le début de l’année visée, par rapport (ii) au CPI publié pour le mois correspondant à un (1) mois avant le début de l’année précédente. S’il y a une augmentation, l’ICANN informera l’opérateur de

registre du montant de l’ajustement en question. Tout ajustement des frais en vertu du présent article 6.5 prendra effet à partir du premier jour du premier trimestre civil commençant au moins trente (30) jours après que l’ICANN a informé l’opérateur de

registre d’un tel ajustement des frais.

6.6 Frais supplémentaires en cas de retard de paiement. Pour tout retard de paiement de trente (30) jours civils ou plus dans le cadre du présent contrat, l’opérateur de registre devra verser des frais supplémentaires sur les retards de paiement à hauteur de 1,5 % par mois de retard ou, pour un retard de moins d’un mois, au taux maximum autorisé par la loi en vigueur.

6.7 Autorisation de réduction des frais. À son entière discrétion, l’ICANN peut réduire le montant des frais de registre exigibles à l’opérateur de registre aux termes des présentes pour une durée quelconque (l’« Autorisation de réduction des frais »). Une telle autorisation de réduction des frais peut, tel que déterminé par l’ICANN à son entière

discrétion, être (a) d’une durée limitée et (b) conditionnée à l’acceptation par l’opérateur de registre des conditions générales énoncées dans cette autorisation. Une autorisation de réduction des frais n’entrera en vigueur que si elle est accordée par écrit par l’ICANN tel que prévu à l’article 7.6(i). L’ICANN informera l’opérateur de registre de toute autorisation de réduction des frais conformément à l’article 7.9.

ARTICLE 7.

DIVERS

7.1 Dédommagement de l’ICANN.

(a) L’opérateur de registre doit dédommager et défendre l’ICANN et ses directeurs, membres de l'équipe de direction, employés et agents (collectivement, « les Indemnisés ») en cas de réclamations de tiers, dommages, responsabilités, coûts et frais, y compris les honoraires et les frais de justice raisonnables, découlant des ou liés aux droits de propriété intellectuelle associés au TLD, à la délégation du TLD à l’opérateur de registre, à l’exploitation du registre par l’opérateur de registre pour le TLD ou à la fourniture de

services de registre par l’opérateur de registre, à condition que l’opérateur de registre ne soit pas tenu de dédommager ou de défendre les indemnisés dans la mesure où les réclamations, les dommages, les responsabilités, les coûts ou les frais découlent : (i) d’actions ou d’omissions de l’ICANN, de ses sous-traitants, des membres de ses panels ou de ses évaluateurs spécifiquement liées au et survenant au cours du processus de candidature au registre TLD (hormis les actions ou omissions requises par ou profitant à l’opérateur de registre), ou (ii) d’un manquement de l’ICANN à l’une de ses obligations prévues dans le présent contrat ou d’une inconduite délibérée de l’ICANN. Le présent

article ne doit pas être interprété comme exigeant de l’opérateur de registre de rembourser ou dédommager l’ICANN au titre des coûts associés à la négociation ou à l’exécution du présent contrat, ou au contrôle ou à la gestion des obligations respectives des parties en vertu des présentes. En outre, le présent article ne s’appliquera pas aux réclamations concernant les honoraires d’avocat liés aux litiges ou aux procédures d’arbitrage entre les parties, qui seront régies par le chapitre 5 ou traitées par un tribunal compétent ou un arbitre.

[Texte alternatif pour l’article 7.1(a) pour les organisations intergouvernementales

ou les entités gouvernementales :

« L’opérateur de registre fera de son mieux pour coopérer avec l’ICANN en vue de s’assurer que l’ICANN n’engage pas de frais associés à des réclamations, dommages, responsabilités, coûts et frais, y compris les honoraires et les frais de justice raisonnables, découlant des ou liés aux droits de propriété intellectuelle associés au TLD, à la délégation du TLD à l’opérateur de registre, à l’exploitation du registre par l’opérateur de registre pour le TLD ou à la fourniture de services de registre par l’opérateur de registre, à condition que l’opérateur de registre ne soit pas tenu de coopérer dans la mesure où les réclamations, les dommages, les responsabilités, les coûts ou les frais découlent d’un manquement de l’ICANN à l’une de ses obligations prévues dans le présent contrat ou d’une inconduite délibérée de l’ICANN. Le présent article ne doit pas être interprété comme exigeant de l’opérateur de registre de rembourser ou dédommager l’ICANN au titre des coûts associés à la négociation ou à l’exécution du présent contrat, ou au contrôle ou à la gestion des obligations respectives des parties en vertu des présentes. En outre, le présent article ne s’appliquera pas aux réclamations concernant les honoraires d’avocat liés aux

litiges ou aux procédures d’arbitrage entre les parties, qui seront régies par le chapitre 5 ou

traitées par un tribunal compétent ou un arbitre. »]

(b) Pour toute demande de dédommagement de l’ICANN dans le cadre de laquelle plusieurs opérateurs de registres (dont l’opérateur de registre) sont impliqués dans les mêmes actions ou omissions qui ont donné lieu à la réclamation, la responsabilité cumulée de l’opérateur de registre eu égard à l’indemnisation de l’ICANN pour ladite

réclamation sera limitée à un pourcentage de la réclamation totale de l’ICANN. Le pourcentage sera calculé en divisant le nombre total des noms de domaine enregistrés auprès de l’opérateur de registre dans le TLD (lesquels noms enregistrés seront calculés conformément au chapitre 6 pour tout trimestre pertinent) par le nombre total des noms de domaine enregistrés dans tous les domaines de premier niveau dans le cadre desquels les opérateurs de registre sont impliqués dans les mêmes actes ou omissions ayant donné lieu à la réclamation. Afin de réduire la responsabilité de l’opérateur de registre au titre de l’article 7.1(a) conformément au présent article 7.1(b), l’opérateur de registre devra identifier les autres opérateurs de registre impliqués dans les mêmes actions ou omissions ayant donné lieu à la réclamation, et démontrer, à la satisfaction raisonnable de l’ICANN, la culpabilité de ces autres opérateurs de registre quant à de telles actions ou omissions. Dans un souci de clarté, si l’opérateur de registre ou les opérateurs de registre sont impliqués dans les mêmes actions ou omissions ayant donné lieu aux réclamations, mais que cet ou ces opérateurs de registre n’ont pas, à l’égard de l’ICANN, les mêmes obligations de dédommagement ou des obligations de dédommagement similaires à celles prévues à

l’article 7.1(a) ci-dessus, le nombre de domaines administrés par cet ou ces opérateurs de registre sera néanmoins inclus dans le calcul de la phrase précédente. [Remarque : le présent article 7.1(b) n’est pas applicable aux organisations intergouvernementales ou entités gouvernementales].

7.2 Procédures de dédommagement. En cas de demande de dédommagement d’un tiers au titre de l’article 7.1 ci-dessus, l’ICANN en informera l’opérateur de registre aussi rapidement que possible. L’opérateur de registre sera autorisé, s’il en décide ainsi dans un avis adressé dans de brefs délais à l’ICANN, à se charger immédiatement de la défense et de l’enquête liées à la réclamation et d’engager des avocats raisonnablement acceptables pour l’ICANN afin d’assurer sa défense, aux frais exclusifs de l’opérateur de

registre, à condition que, dans tous les cas, l’ICANN soit autorisée à contrôler, à ses propres frais, l’examen des questions liées à la validité ou à l’interprétation des politiques, des statuts constitutifs ou de la conduite de l’ICANN. L’ICANN devra coopérer, aux frais de l’opérateur de registre et à tous égards raisonnables, avec l’opérateur de registre et ses avocats dans le cadre de l'enquête, du procès et de la défense de ladite réclamation et de tout appel pouvant en découler, et pourra, à ses frais exclusifs, participer, par

l’intermédiaire de ses avocats ou autres, à l’enquête, au procès et à la défense de ladite réclamation et à tout appel pouvant en découler. Dans le cadre d’une réclamation, il ne sera pas possible de parvenir à un règlement qui impliquerait un recours affectant l’ICANN

autre que le paiement d’une somme d’argent entièrement prise en charge par l’opérateur de registre sans le consentement de l’ICANN. Si l’opérateur de registre n’assume pas le contrôle total de la défense dans le cadre d’une réclamation soumise à une telle défense conformément au présent article 7.2, l’ICANN pourra assurer la défense dans le cadre de la

réclamation de la manière qu’elle considère juste, aux frais et dépens de l’opérateur de registre et celui-ci devra coopérer dans le cadre de cette défense. [Remarque : le présent article 7.2 n’est pas applicable aux organisations intergouvernementales ou entités gouvernementales].

7.3 Définition des termes. Aux fins du présent contrat, sauf si ces définitions sont ultérieurement amendées conformément à une politique de consensus, auquel cas les définitions suivantes seront réputées amendées et rétablies dans leur totalité tel que décrit dans la politique de consensus en question, les termes « sécurité » et « stabilité » sont définis comme suit :

(a) Aux fins du présent contrat, un effet sur la « sécurité » désigne (i) la

divulgation, la modification, l’insertion ou la destruction non autorisée de données

d’enregistrement, ou (ii) l’accès non autorisé à ou la divulgation non autorisée

d’informations ou de ressources sur l’Internet par des systèmes opérant conformément à

toutes les normes applicables.

(b) Aux fins du présent contrat, un effet sur la « stabilité » désigne (1) le non-respect des normes correspondantes applicables faisant autorité et publiées par un organe de normalisation d’Internet bien établi et reconnu telles que les normes Appels à commentaires (« RFC ») sur les meilleures pratiques actuelles ou sur le processus de

standardisation d’Internet parrainées par le Groupe de travail de génie Internet (IETF) ; ou

(2) la création d’une condition qui affecte défavorablement le débit, le temps de réponse et la cohérence des réponses aux serveurs Internet ou systèmes finaux opérant selon les normes correspondantes applicables faisant autorité et publiées par un organe de

normalisation d’Internet bien reconnu et établi telles que les normes RFC sur les meilleures

pratiques actuelles ou sur le processus de standardisation d’Internet, et dépendant des services d’approvisionnement ou d’informations déléguées de l’opérateur de registre.

7.4 Absence de compensation. Tous les paiements dus au titre du présent contrat seront effectués dans les délais impartis tout au long de la durée du présent contrat et en dépit de l’existence d’un litige en suspens (monétaire ou autre) entre l’opérateur de

registre et l’ICANN.

7.5 Changement de contrôle, cession et sous-traitance. Sauf tel que prévu à l’article 7.5, aucune des parties ne pourra céder l’un quelconque de ses droits et obligations prévus par le présent contrat sans l’autorisation écrite préalable de l’autre partie, autorisation qui ne doit pas être refusée sans motif raisonnable. Aux fins du présent article 7.5, un changement direct ou indirect du contrôle de l’opérateur de registre ou tout contrat de sous-traitance lié à des fonctions critiques (telles qu’identifiées à l’article 6 de la spécification 10) pour le TLD (un « Contrat de sous-traitance partiel de fonctions

critiques ») sera considéré comme une cession.

(a) L’opérateur de registre doit donner à l’ICANN un préavis d’au moins trente (30) jours civils l’informant de toute cession ou tout contrat de sous-traitance partiel de fonctions critiques, et tout accord visant à céder ou sous-traiter une partie quelconque

des opérations du TLD (qu’il s’agisse ou non d’un contrat de sous-traitance partiel de fonctions critiques) doit imposer le respect de tous les engagements, obligations et accords convenus par l’opérateur de registre au titre du présent contrat et l’opérateur de registre doit continuer à être lié par de tels engagements, obligations et accords. L’opérateur de

registre doit également donner à l’ICANN un préavis d’au moins trente (30) jours civils avant l’exécution de toute transaction dont le résultat escompté est un changement direct ou indirect de contrôle de l’opérateur de registre.

(b) Dans les trente (30) jours civils suivant l’un desdits préavis

conformément à l’article 7.5(a), l’ICANN peut demander à l’opérateur de registre de fournir

des informations supplémentaires établissant (i) la conformité avec le présent contrat et

(ii) que la partie prenant en charge ce contrôle ou concluant cette cession ou ce contrat de sous-traitance partiel de fonctions critiques (dans tous les cas, la « Partie contractante ») et la société mère de la partie contractante respectent la spécification ou la politique adoptée par l’ICANN sur les critères liés aux opérateurs de registre alors en vigueur (y compris pour ce qui est des ressources financières et des capacités opérationnelles et techniques), auquel cas l’opérateur de registre doit fournir les informations requises dans un délai de quinze

(15) jours civils.

(c) L’opérateur de registre accepte que le consentement de l’ICANN à toute cession, à tout changement de contrôle ou à tout contrat de sous-traitance partiel de fonctions critiques soit également soumis à des vérifications d’antécédents de toute partie contractante proposée (ainsi que des sociétés affiliées de ladite partie contractante).

(d) Si l’ICANN omet de fournir ou refuser expressément son consentement à une cession, à un changement direct ou indirect de contrôle de l’opérateur de registre ou à un contrat de sous-traitance partiel de fonctions critiques dans les trente

(30) jours civils à compter de la réception de la part de l’ICANN de l’avis informant de cette transaction (ou, si l’ICANN a demandé des informations supplémentaires à l’opérateur de

registre tel qu’indiqué ci-dessus, dans les trente (30) jours civils à compter de la réception de toutes les informations écrites demandées concernant ladite transaction), l’ICANN sera réputée avoir consenti à une telle transaction.

(e) Eu égard à une telle cession, à un tel changement de contrôle ou à un tel contrat de sous-traitance partiel de fonctions critiques, l’opérateur de registre doit se conformer au processus de transition entre opérateurs de registre.

(f) En dépit des dispositions précédentes, (i) aucun changement de contrôle accompli ne sera révocable par l’ICANN, à condition, toutefois, que si l’ICANN décide, dans la mesure du raisonnable, de refuser son consentement à ladite transaction, l’ICANN puisse résilier le présent contrat conformément à l’article 4.3(g), (ii) l’ICANN pourra céder le présent contrat sans l’autorisation de l’opérateur de registre suite à l’approbation du Conseil d’administration de l’ICANN dans le cadre d’une restructuration, d’une reconstitution ou d’une réincorporation de l’ICANN après l’acceptation expresse par ledit cessionnaire des conditions générales du présent contrat, (iii) l’opérateur de registre pourra céder le présent contrat sans l’autorisation de l’ICANN directement à un cessionnaire affilié, terme défini ci- après, après l’acceptation expresse par ledit cessionnaire affilié des conditions générales du présent contrat, et (iv) l’ICANN sera réputée avoir autorisé toute cession, tout contrat de sous-traitance partiel de

fonctions critiques ou toute transaction instaurant un changement de contrôle dans le cadre duquel la partie contractante est un opérateur existant d’un domaine de premier niveau générique en vertu d’un contrat de registre conclu entre ladite partie contractante et l’ICANN (à condition que ladite partie contractante soit alors en conformité, à tous égards importants, avec les conditions générales d’un tel contrat de registre), à moins que l’ICANN ne présente à l’opérateur de registre une objection écrite à ladite transaction dans les dix (10) jours civils à compter de la réception par l’ICANN de l’avis l’informant de ladite transaction en vertu du présent article 7.5. Nonobstant l’article 7.5(a), dans l’hypothèse où une cession serait réalisée en vertu des clauses (ii) ou (iii) du présent article 7.5(f), la partie cédante informera l’autre partie de cette cession dans les plus brefs délais. Aux fins du présent article 7.5(f), (A) « cessionnaire affilié » désigne une personne physique ou morale qui, directement ou indirectement, via un ou plusieurs intermédiaires, contrôle, est contrôlée par ou est placée sous contrôle commun avec la personne physique ou morale indiquée, et (B) « contrôle » (y compris les termes « contrôlé(e) par » et « sous contrôle commun avec ») a la même signification que celle indiquée à l’article 2.9 (c) du présent contrat.

7.6 Amendements et renonciations.

(a) Dans l’hypothèse où le Conseil d’administration de l’ICANN

déterminerait qu’un amendement du présent contrat (y compris des spécifications qui y sont mentionnées) et de tous les autres contrats de registre conclus entre l’ICANN et les opérateurs de registre concernés (les « Contrats de registre applicables » ) est souhaitable (individuellement, un « Amendement spécial » ), l’ICANN pourra adopter un amendement spécial, conformément aux exigences et aux processus prévus dans le présent article 7.6, à condition qu’un amendement spécial ne puisse être un amendement restreint.

(b) Avant de soumette un amendement spécial à l’approbation de l’opérateur de registre, l’ICANN consultera dans un premier temps en toute bonne foi le

Groupe de travail sur la forme et le contenu dudit amendement spécial. La durée d’une telle consultation sera raisonnablement décidée par l’ICANN sur le fondement du contenu de l’amendement spécial. Suite à une telle consultation, l’ICANN pourra proposer l’adoption d’un amendement spécial en publiant ledit amendement sur son site web pendant au moins trente (30) jours civils (la « Période de publication ») et en informant les opérateurs de

registre concernés dudit amendement proposé conformément à l’article 7.9. L’ICANN examinera les commentaires publics concernant l’amendement spécial reçus au cours de la période de publication (y compris les commentaires soumis par les opérateurs de registre concernés).

(c) Si, dans les cent quatre-vingts (180) jours civils à compter de l’expiration de la période de publication (la « Période d’approbation »), le Conseil d’administration de l’ICANN approuve un amendement spécial (qui peut prendre une

forme différente de la forme de l’amendement spécial soumis à consultation publique, mais doit aborder la question traitée par l’amendement spécial publié à des fins de consultation publique, l’amendement spécial étant modifié pour refléter et/ou prendre en compte les contributions du Groupe de travail et les commentaires publics), l’ICANN informera les opérateurs de registre concernés dudit amendement spécial et le soumettra à ces derniers à des fins d’approbation ou de désapprobation. Si, pendant la période de soixante (60)

jours civils à compter de la date à laquelle l’ICANN informe les opérateurs de registre concernés dudit amendement spécial, un tel amendement spécial obtient l’approbation des opérateurs de registre, il sera réputé approuvé (un « Amendement approuvé ») par les opérateurs de registre concernés, et entrera en vigueur et sera réputé constituer un amendement du présent contrat soixante (60) jours civils après la date à laquelle l’ICANN a informé l’opérateur de registre de l’approbation dudit amendement approuvé (la « Date d’entrée en vigueur de l’amendement »). Si un amendement spécial ne reçoit pas

l’approbation de l’opérateur de registre, l’amendement spécial sera réputé ne pas être approuvé par les opérateurs de registre concernés (un « Amendement rejeté »). Un amendement rejeté n’aura aucune conséquence sur les conditions générales du présent contrat, sauf tel qu’indiqué ci-dessous.

(d) Si le Conseil d’administration de l’ICANN détermine raisonnablement qu’un amendement rejeté relève des catégories d’objet énoncées dans l’article 1.2 de la spécification 1, le Conseil d’administration de l’ICANN pourra adopter une résolution (la date d’adoption de cette résolution est dénommée ci-après « Date d’adoption de la résolution ») demandant à l’Organisation de soutien aux extensions génériques (la

« GNSO ») de fournir un « rapport thématique » (tel que défini dans les statuts constitutifs de l’ICANN) quant au contenu dudit amendement rejeté. Le processus d’élaboration de politiques mené par la GNSO conformément à ce rapport thématique exigé est désigné dans les présentes « PDP ». Si un tel PDP aboutit à un rapport final soutenu par une majorité qualifiée de la GNSO (telle que définie dans les statuts constitutifs de l’ICANN) qui soit (i)

recommande l’adoption de l’amendement rejeté en tant que politique de consensus, soit (ii) se prononce contre l’adoption de l’amendement rejeté en tant que politique de consensus et, dans le cas prévu au point (i) ci-dessus, si le Conseil d’administration adopte cette politique de consensus, l’opérateur de registre devra s’acquitter de ses obligations

conformément à l’article 2.2 du présent contrat. Dans les deux cas, l’ICANN abandonnera l’amendement rejeté et celui-ci n’aura aucune conséquence sur les conditions générales du présent contrat. Nonobstant les dispositions précédentes du présent article 7.6(d), le

Conseil d’administration de l’ICANN ne sera pas tenu de lancer un PDP sur un amendement rejeté si, à tout moment lors de la période de douze (12) mois précédant la présentation de cet amendement rejeté à des fins d’approbation de l’opérateur de registre conformément à l’article 7.6(c), l’objet de cet amendement rejeté a été soumis à un PDP conclu, abandonné ou auquel il a été mis un terme n’ayant pas entraîné une recommandation de la majorité qualifiée de la GNSO.

(e) Si (a) un amendement rejeté ne relève pas des catégories d’objet énoncées à l’article 1.2 de la spécification 1, (b) l’objet d’un amendement rejeté a été, à tout moment lors de la période de douze (12) mois précédant la présentation de cet amendement rejeté à des fins d’approbation de l’opérateur de registre conformément à

l’article 7.6(c), soumis à un PDP conclu, abandonné ou auquel il a été mis un terme n’ayant pas entraîné une recommandation de la majorité qualifiée de la GNSO, ou (c) un PDP n’aboutit pas à un rapport final soutenu par la majorité qualifiée de la GNSO qui soit (A)

recommande l’adoption de l’amendement rejeté en tant que politique de consensus, soit

(B) se prononce contre l’adoption de l’amendement rejeté en tant que politique de consensus (ou si un tel PDP a été abandonné ou s’il a été mis un terme à un tel PDP pour un

motif quelconque), alors, dans de tels cas, ledit amendement rejeté pourra quand même être adopté et entrer en vigueur de la manière décrite ci-dessous. Pour l’adoption de l’amendement rejeté, les conditions suivantes doivent être remplies :

(i) l’objet de l’amendement rejeté doit relever de la mission de l’ICANN et être compatible avec une application équilibrée de ses valeurs fondamentales (telles que décrites dans les statuts constitutifs de l’ICANN) ;

(ii) l’amendement rejeté doit être justifié par une raison importante et déterminante dans l’intérêt public, doit être à même de

promouvoir un tel intérêt, en tenant compte des intérêts publics et privés concurrents qui sont susceptibles d’être affectés par l’amendement rejeté, et doit être strictement adapté et ne pas avoir une portée plus large que ce qui est raisonnablement nécessaire afin de tenir compte de cette raison

importante et déterminante dans l’intérêt public ;

(iii) dans la mesure où l’amendement rejeté interdit ou exige une conduite ou des activités, impose des coûts importants aux opérateurs de registre concernés et/ou réduit considérablement l’accès du public aux

services de noms de domaine, l’amendement rejeté doit constituer le moyen le moins restrictif raisonnablement disponible afin de tenir compte de cette raison importante et déterminante dans l’intérêt public ;

(iv) le Conseil d’administration de l’ICANN doit présenter l’amendement rejeté à des fins de consultation publique pendant une période minimale de trente (30) jours civils, accompagné d’une explication écrite justifiant sa décision selon laquelle l’amendement rejeté remplit les conditions prévues aux paragraphes (i) à (iii) ci-dessus ; et

(v) suite à cette période de consultation publique, le Conseil d’administration de l’ICANN doit (a) procéder à des consultations (ou enjoindre à la direction de l’ICANN de procéder à de telles consultations) avec le Groupe de travail, les experts en la matière, les membres de la GNSO, les comités consultatifs concernés et autres parties prenantes intéressées sur ledit amendement rejeté pendant une période minimale de soixante (60) jours civils ; et (b) suite à ces consultations, réapprouver l’amendement

rejeté (qui peut prendre une forme différente de la forme de l’amendement spécial soumis à des fins d’approbation de l'opérateur de registre, mais doit aborder la question traitée par l’amendement spécial, l’amendement spécial étant modifié pour refléter et/ou prendre en compte les contributions du Groupe de travail et les commentaires publics) par le vote favorable d’au moins les deux tiers des membres du Conseil d’administration de l’ICANN

ayant le droit de voter sur cette question, en tenant compte de toute politique de l’ICANN ayant une incidence sur ce droit de vote, y compris la politique de gestion des conflits d'intérêts de l’ICANN (un « Amendement du Conseil d’administration »).

Un tel amendement du Conseil d’administration, sous réserve de l’article 7.6(f), sera réputé être un amendement approuvé, et entrera en vigueur et sera réputé constituer un amendement du présent contrat soixante (60) jours civils après la date à laquelle l’ICANN a informé l’opérateur de registre de l’approbation dudit amendement du Conseil

d’administration (ladite date d’entrée en vigueur sera réputée être la date d’entrée en vigueur de l’amendement en vertu des présentes). Nonobstant les dispositions

précédentes, un amendement du Conseil d’administration ne peut ni modifier les frais facturés par l’ICANN aux opérateurs de registre en vertu des présentes ni amender le présent article 7.6.

(f) Nonobstant les dispositions de l’article 7.6(e), un amendement du Conseil d’administration ne sera réputé être un amendement approuvé si, au cours de la

période de trente (30) jours civils à compter de l’approbation de l’amendement du Conseil d’administration par le Conseil d’administration de l’ICANN, le Groupe de travail, au nom des opérateurs de registre concernés, soumet au Conseil d’administration de l’ICANN un amendement du Conseil d’administration alternatif (un « Amendement alternatif ») qui répond aux exigences suivantes :

(i) énonce le texte exact proposé par le Groupe de travail pour amender le présent contrat à la place de l’amendement du Conseil d’administration ;

(ii) aborde la raison importante et déterminante dans l’intérêt public identifiée par le Conseil d’administration de l’ICANN en tant que justification de l’amendement du Conseil d’administration ; et

(iii) par rapport à l'amendement du Conseil d’administration : (a) est plus strictement adapté pour aborder ladite raison importante et

déterminante dans l’intérêt public, et (b) dans la mesure où l’amendement alternatif interdit ou exige une conduite ou des activités, impose des coûts importants aux opérateurs de registre concernés ou réduit considérablement l’accès aux services de noms de domaine, constitue le moyen le moins restrictif afin de tenir compte de la raison importante et déterminante dans l’intérêt public.

Toute proposition d’amendement ne répondant pas aux exigences des paragraphes (i) à

(iii) de la phrase précédente ne sera pas réputée être un amendement alternatif aux termes

des présentes et, par conséquent, ne remplacera pas l’amendement du Conseil d’administration et ne retardera pas son entrée en vigueur. Si, suite à la présentation de l’amendement alternatif au Conseil d’administration de l’ICANN, l’amendement alternatif est approuvé par l’opérateur de registre, l’amendement alternatif remplacera l’amendement du Conseil d’administration et sera réputé être un amendement approuvé aux termes des présentes (et entrera en vigueur et sera réputé constituer un amendement du présent contrat soixante (60) jours civils après la date à laquelle l’ICANN a informé l’opérateur de registre de l’approbation dudit amendement alternatif, ladite date d’entrée en vigueur sera réputée être la date d’entrée en vigueur de l’amendement en vertu des

présentes), à moins qu’au cours de la période de soixante (60) jours civils à compter de la date à laquelle le Groupe de travail informe le Conseil d’administration de l’ICANN de l’approbation de l’opérateur de registre dudit amendement alternatif (période pendant laquelle l’ICANN échangera avec le Groupe de travail eu égard à l’amendement alternatif), le Conseil d’administration de l’ICANN, par le vote favorable d’au moins les deux tiers des membres du Conseil d’administration de l’ICANN ayant le droit de voter sur cette question, en tenant compte de toute politique de l’ICANN ayant une incidence sur ce droit de vote, y compris la politique de gestion des conflits d'intérêts de l’ICANN, rejette l’amendement alternatif. Si (A) l’amendement alternatif n’est pas approuvé par l’opérateur de registre dans un délai de trente (30) jours à compter de la présentation dudit amendement

alternatif aux opérateurs de registre concernés (et le Groupe de travail informera l’ICANN de la date d’une telle présentation), ou (B) le Conseil d’administration de l’ICANN rejette l’amendement alternatif par un vote des deux tiers, l’amendement du Conseil

d’administration (et non l’amendement alternatif) entrera en vigueur et sera réputé constituer un amendement du présent contrat soixante (60) jours civils après la date à laquelle l’ICANN a informé l’opérateur de registre (ladite date d’entrée en vigueur sera réputée être la date d’entrée en vigueur de l’amendement en vertu des présentes). Si le Conseil d’administration de l’ICANN rejette un amendement alternatif, le Conseil d'administration devra publier une justification écrite exposant son analyse des critères

énoncés dans les articles 7.6(f)(i) à 7.6(f)(iii). La capacité du Conseil d’administration de l’ICANN à rejeter un amendement alternatif aux termes des présentes ne libère pas le

Conseil d’administration de l’obligation de garantir que tout amendement du Conseil d’administration réponde aux critères énoncés dans les articles 7.6(e)(i) à 7.6(e)(v).

(g) Dans l’hypothèse où l’opérateur de registre estimerait qu’un

amendement approuvé ne remplit pas les conditions de fond énoncées dans le présent

article 7.6 ou a été adopté en violation de l’une quelconque des dispositions procédurales prévues au présent article 7.6, l’opérateur de registre pourra contester l’adoption d’un tel amendement spécial conformément aux dispositions relatives au règlement de litiges énoncées dans le chapitre 5, sauf que cette procédure d’arbitrage devra être menée par un panel d’arbitrage composé de trois personnes. Une telle contestation doit être introduite dans les soixante (60) jours civils à compter de la date à laquelle l’ICANN a informé

l’opérateur de registre de l’amendement approuvé, et l’ICANN pourra regrouper toutes les contestations introduites par les opérateurs de registre (y compris l’opérateur de registre) en une seule et même procédure. L’amendement approuvé sera réputé ne pas avoir amendé le présent contrat pendant la durée du processus de règlement de litiges.

(h) L’opérateur de registre pourra faire une demande écrite à l’ICANN d’exemption à l’amendement approuvé (chaque demande soumise par l’opérateur de registre en vertu des présentes étant une « Demande d’exemption ») pendant la période de trente (30) jours civils à compter de la date à laquelle l’ICANN a informé l’opérateur de registre dudit amendement approuvé. Chaque demande d’exemption décrira le fondement d’une telle demande et fournira une justification détaillée de l’exemption à l’amendement approuvé. Une demande d’exemption pourra également inclure une description détaillée et la justification d’alternatives ou de variations de l’amendement approuvé proposées par ledit opérateur de registre. Une demande d’exemption pourra uniquement être octroyée si

l’opérateur de registre démontre de manière claire et convaincante que le respect de l’amendement approuvé est en contradiction avec la législation applicable ou aurait un effet défavorable substantiel sur la situation financière à long terme ou les résultats des activités de l’opérateur de registre. Aucune demande d’exemption ne sera octroyée si l’ICANN décide, à sa discrétion raisonnable, que l’octroi d’une telle exemption porterait

considérablement atteinte aux titulaires de noms de domaine ou entraînerait une absence de bénéfice direct pour les titulaires de noms de domaine. Dans les quatre-vingt-dix (90) jours civils à compter de la réception d’une demande d’exemption par l’ICANN, l’ICANN approuvera (cette approbation pouvant être assortie de conditions ou prendre la forme d’alternatives ou de variations de l’amendement approuvé) ou refusera l’exemption par écrit. Pendant cette période, l’amendement approuvé n’amendera pas le présent contrat. Si la demande d’exemption est approuvée par l’ICANN, l’amendement approuvé n’amendera pas le présent contrat, à condition que toutes les conditions, alternatives ou variations de l’amendement approuvé exigées par l’ICANN entrent en vigueur et, dans la mesure du possible, amendent le présent contrat à compter de la date d’entrée en vigueur de l’amendement. Si une telle demande d’exemption est refusée par l’ICANN, l’amendement approuvé amendera le présent contrat à compter de la date d’entrée en vigueur de l’amendement (ou, si cette date est passée, ledit amendement approuvé sera réputé entrer en vigueur immédiatement à la date du refus), à condition que l’opérateur de registre puisse, dans les trente (30) jours civils à compter de la réception de la décision de l’ICANN, faire appel de la décision de l’ICANN de refuser la demande d’exemption, conformément aux procédures de règlement de litiges prévues au chapitre 5. L’amendement approuvé sera réputé ne pas avoir amendé le présent contrat pendant la durée du processus de règlement de litiges. Dans un souci de clarté, seules les demandes d’exemption soumises par l’opérateur de registre et approuvées par l’ICANN conformément au présent article 7.6(j), acceptées par l’ICANN suite à une procédure de médiation conformément à l’article

5.1 ou approuvées suite à une décision d’arbitrage conformément à l’article 5.2

dispenseront l’opérateur de registre de l’application de l’amendement approuvé et aucune demande d’exemption accordée à un autre opérateur de registre concerné (que ce soit par l’ICANN ou par le biais de l’arbitrage) n’aura d’effet au titre du présent contrat ou ne dispensera l’opérateur de registre de l’application d’un amendement approuvé.

(i) Sauf tel que prévu dans le présent article 7.6, dans l’article 7.7, dans d’autres dispositions du présent contrat et dans les spécifications du présent contrat, aucun amendement, supplément ou modification du présent contrat ou de l’une de ses dispositions n’engagera les parties sauf si elles s’y engagent toutes les deux par écrit et aucune disposition de ces articles 7.6 ou 7.7 n’empêchera l’ICANN et l’opérateur de registre de conclure des amendements et des modifications bilatéraux du présent contrat uniquement négociés par les deux parties. Aucune renonciation à l’une des dispositions du présent contrat n’est exécutoire sauf si elle fait l’objet d’un écrit signé par la partie qui renonce à respecter la disposition en question. Aucune renonciation à l’une des dispositions du présent contrat ou absence d’application de l’une de ses dispositions ne sera réputée être ou ne constituera une renonciation aux autres dispositions et ne constituera non plus une renonciation continue sauf disposition contraire explicite. Dans un souci de clarté, aucune disposition de ces articles 7.6 ou 7.7 ne sera réputée limiter l’obligation de l’opérateur de registre de se conformer à l’article 2.2.

suivantes :

(j) Aux fins de l’article 7.6, les termes suivants auront les significations

(i) « Opérateurs de registre concernés » désigne, collectivement, les opérateurs de registre de domaines de premier niveau parties à un contrat de registre qui comprend une disposition similaire au présent article 7.6, y compris l’opérateur de registre.

(ii) « Approbation de l’opérateur de registre » désigne la réception de chacune des approbations suivantes : (A) l’approbation affirmative des opérateurs de registre concernés dont les paiements à l’ICANN représentent les deux tiers du montant total des frais (convertis en USD, le cas échéant, au taux de change publié le jour avant dans l’édition américaine du Wall Street Journal pour la date à laquelle le calcul est effectué par l’ICANN) payés à

l’ICANN par tous les opérateurs de registre concernés durant l’année civile précédente conformément aux contrats de registre applicables, et (B) l’approbation affirmative d’une majorité des opérateurs de registre concernés au moment de l’obtention d’une telle approbation. Dans un souci de clarté, concernant la clause (B), chaque opérateur de registre concerné

disposera d’un vote pour chaque domaine de premier niveau exploité par cet

opérateur de registre conformément à un contrat de registre applicable.

(iii) « Amendement restreint » désigne ce qui suit : (A) un

amendement de la spécification 1, (B) sauf dans la mesure indiquée à l’article

2.10 des présentes, un amendement qui précise le prix facturé par

l’opérateur de registre aux bureaux d’enregistrement pour les enregistrements de noms de domaine, (C) un amendement à la définition des services de registre tels que décrits au premier paragraphe de l’article 2.1 de la spécification 6, ou (D) un amendement apporté à la durée du contrat.

(iv) « Raison importante et déterminante dans l’intérêt public » désigne une raison qui est justifiée par un objectif d’intérêt public important, spécifique et formulé qui relève de la mission de l’ICANN et est compatible avec une application équilibrée des valeurs fondamentales de l’ICANN telles que définies dans les statuts constitutifs de l’ICANN.

(v) « Groupe de travail » désigne des représentants des opérateurs de registre concernés et d’autres membres de la communauté occasionnellement nommés par le Groupe des représentants des opérateurs de registre afin d’agir en tant que groupe de travail pour la consultation

relative aux amendements des contrats de registre applicables (à l’exception

des amendements bilatéraux visés à l'article 7.6(i)).

(k) Nonobstant toute disposition contraire du présent article 7.6, (i) si

l’opérateur de registre démontre, à la satisfaction raisonnable de l’ICANN, que l’amendement approuvé augmenterait considérablement le coût de la fourniture des

services de registre, l’ICANN accordera un délai maximum de cent quatre-vingts (180) jours civils pour l’entrée en vigueur de l’amendement approuvé à l’égard de l’opérateur de registre, et (ii) aucun amendement approuvé conformément à l’article 7.6 n’entrera en vigueur à l’égard de l’opérateur de registre tant que l’opérateur de registre présente à

l’ICANN un avis irrévocable de résiliation conformément à l’article 4.4(b).

7.7 Processus de négociation.

(a) Si soit le président-directeur général de l’ICANN (le « PDG ») soit le président du Groupe des représentants des opérateurs de registre (le « Président ») souhaite discuter de révisions du présent contrat, le PDG ou le président, selon le cas, en informera l’autre par écrit en exposant de façon suffisamment détaillée les révisions proposées du présent contrat (un « Avis de négociation »). Nonobstant la disposition précédente, ni le PDG ni le président ne pourront (i) proposer des révisions du présent contrat qui modifient une politique de consensus alors en vigueur, (ii) proposer des révisions du présent contrat conformément au présent article 7.7 avant le 30 Juin 2014 (inclus), ou (iii) proposer des révisions ou soumettre un avis de négociation plus d’une fois au cours de toute période de douze (12) mois à compter du 1er juillet 2014.

(b) Suite à la réception de l’avis de négociation soit par le PDG, soit par le président, l’ICANN et le Groupe de travail (tel que défini à l’article 7.6) procéderont à des négociations en toute bonne foi concernant la forme et le contenu des révisions proposées du présent contrat, qui prendront la forme d’un amendement proposé du présent contrat (les « Révisions proposées »), pour une période minimale de quatre-vingt-dix (90) jours civils (sauf si une résolution est adoptée avant ce délai), et tenteront de parvenir à un accord mutuellement acceptable concernant les révisions proposées (la « Période de discussion »).

(c) Si, suite à la période de discussion, il est parvenu à un accord sur les révisions proposées, l'ICANN publiera les révisions proposées mutuellement convenues sur son site web à des fins de consultation publique pendant une période minimale de trente

(30) jours civils (la « Période de publication ») et informera de ces révisions tous les opérateurs de registre concernés conformément à l'article 7.9. L’ICANN et le Groupe de travail prendront en considération les commentaires publics concernant les révisions proposées reçus au cours de la période de publication (y compris les commentaires soumis par les opérateurs de registre concernés). Suite à la période de publication, les révisions

proposées seront soumises à l’approbation de l’opérateur de registre (tel que défini à

l’article 7.6) et à l’approbation du Conseil d’administration de l’ICANN. Si ces approbations sont obtenues, les révisions proposées seront réputées constituer un amendement

approuvé (tel que défini à l’article 7.6) par les opérateurs de registre concernés et l’ICANN, et entreront en vigueur et seront réputées constituer un amendement du présent contrat soixante (60) jours civils après la date à laquelle l’ICANN en a informé l’opérateur de registre.

(d) Si, suite à la période de discussion, l’ICANN et le Groupe de travail ne

parviennent pas à un accord sur les révisions proposées, soit le PDG soit le président

pourra envoyer à l’autre partie un avis écrit (l’« Avis de médiation ») demandant à chaque partie de tenter de résoudre les désaccords liés aux révisions proposées via une médiation impartiale et de facilitation (non d’évaluation), conformément aux conditions générales énoncées ci-dessous. Si un avis de médiation est envoyé, l’ICANN et le Groupe de travail, dans les quinze (15) jours civils à compter de la date de réception, publieront simultanément le texte de leur version souhaitée des révisions proposées et un exposé de principe à ce sujet sur le site web de l’ICANN.

(i) La médiation sera menée par un seul médiateur choisi par les parties. Si les parties ne parviennent pas à se mettre d’accord sur un médiateur dans les quinze (15) jours civils à compter de la réception par le PDG ou le président, selon le cas, de l’avis de médiation, les parties devront sélectionner rapidement un prestataire de services de médiation mutuellement acceptable qui devra, dès que possible suite à sa sélection, désigner un médiateur, qui sera un avocat agréé disposant de connaissances générales en matière de droit des contrats, n’ayant aucune relation commerciale avec les parties, et disposant de connaissances générales du système des noms de domaine lui permettant de statuer sur le litige en question. Le médiateur devra confirmer par écrit qu’il n’est pas, et ne deviendra pas pendant la durée de la médiation, un employé, un associé, un cadre, un directeur ou un détenteur de titres de l’ICANN ou de l’opérateur de registre concerné. En cas d’absence de confirmation de la part du médiateur désigné, un médiateur remplaçant sera nommé conformément au présent article 7.7(d)(i).

(ii) Le médiateur mènera la médiation en conformité avec les règles et procédures qu’il déterminera, pour la médiation de facilitation, après consultation des parties. Les parties discuteront du litige en toute

xxxxx foi et tenteront, avec l’aide du médiateur, de parvenir à un règlement à l’amiable du litige.

(iii) Chaque partie assumera ses propres frais liés à la médiation. Les parties prendront en charge à parts égales les honoraires et les frais du médiateur.

(iv) S’il est parvenu à un accord au cours de la médiation, l’ICANN devra publier les révisions proposées mutuellement convenues sur son site web pendant la période de publication et en informera tous les opérateurs de registre concernés conformément à l’article 7.9. L’ICANN et le Groupe de travail examineront les commentaires publics concernant les révisions proposées convenues reçus au cours de la période de publication (y compris les commentaires soumis par les opérateurs de registre concernés). Suite à la période de publication, les révisions proposées seront soumises à

l’approbation de l’opérateur de registre et à l’approbation du Conseil d’administration de l’ICANN. Si ces approbations sont obtenues, les révisions proposées seront réputées constituer un amendement approuvé (tel que

défini à l’article 7.6) par les opérateurs de registre concernés et l’ICANN, et entreront en vigueur et seront réputées constituer un amendement du présent contrat soixante (60) jours civils après la date à laquelle l’ICANN en a informé l’opérateur de registre.

(v) Si les parties n’ont pas réglé le litige pour quelque raison que ce soit quatre-vingt-dix (90) jours civils après la date de réception par le PDG ou le président, selon le cas, de l’avis de médiation, il sera automatiquement mis un terme à la médiation (à moins qu’elle ne soit prolongée suite à un accord entre les parties). Le médiateur remettra aux parties une définition des questions qui pourraient être posées lors d’un éventuel futur arbitrage.

Ces questions seront soumises aux restrictions énoncées dans l’article

7.7(e)(ii) ci-dessous.

(e) Si, suite à la médiation, l’ICANN et le Groupe de travail ne parviennent pas à un accord sur les révisions proposées, soit le PDG soit le président pourra donner à l’autre partie un avis écrit (un « Avis d’arbitrage ») exigeant à l’ICANN et aux opérateurs de registre concernés de régler le litige via une procédure d’arbitrage exécutoire

conformément aux dispositions relatives à l’arbitrage de l’article 5.2, sous réserve des

conditions et des restrictions du présent article 7.7(e).

(i) Si un avis d’arbitrage est envoyé, la définition des questions du médiateur ainsi que les révisions proposées (soit celles de l’ICANN, soit celles du groupe de travail, soit les deux) devront être publiées à des fins de consultation publique sur le site web de l’ICANN pendant une période minimale de trente (30) jours civils. L’ICANN et le Groupe de travail examineront les commentaires publics concernant les révisions proposées soumis au cours de la période de publication (y compris les commentaires soumis par les opérateurs de registre concernés) et présenteront les informations concernant de tels commentaires ainsi que leurs avis à un panel de trois (3) arbitres. Chaque partie pourra modifier ses révisions proposées avant et après la période de publication. La procédure d’arbitrage ne pourra pas commencer avant la clôture de la période de consultation publique, et l’ICANN pourra regrouper toutes les contestations introduites par les

opérateurs de registre (y compris l’opérateur de registre) en une seule et même procédure. Sauf tel que prévu dans le présent article 7.7, l’arbitrage sera effectué conformément à l’article 5.2.

(ii) Aucun litige concernant les révisions proposées ne pourra être soumis à l’arbitrage si l’objet des révisions proposées (i) est lié à une politique de consensus, (ii) relève des catégories d’objet énoncées dans

l’article 1.2 de la spécification 1, ou (iii) vise à modifier l’une des dispositions ou des spécifications suivantes du présent contrat : les chapitres 1, 3 et 6, les articles 2.1, 2.2, 2.5, 2.7, 2.9, 2.10, 2.16, 2.17, 2.19, 4.1, 4.2, 7.3, 7.6, 7.7, 7.8,

7.10, 7.11, 7.12, 7.13, 7.14, 7.16, l’article 2.8 et la spécification 7 (mais

seulement dans la mesure où les révisions proposées visent à mettre en place

un mécanisme de protection des droits (RPM) qui n’est pas visé par l’article

2.8 et la spécification 7), l’annexe A et les spécifications 1, 4, 6, 10 et 11.

(iii) Le médiateur informera le panel d’arbitres des propositions respectives de l’ICANN et du Groupe de travail concernant les révisions proposées.

(iv) Aucun amendement du présent contrat relatif aux révisions

proposées ne pourra être soumis à l’arbitrage, soit par le Groupe de travail, soit par l’ICANN, à moins que, dans le cas du Groupe de travail, la proposition d’amendement ait reçu l’approbation de l’opérateur de registre et, dans le cas de l’ICANN, la proposition d’amendement ait été approuvée par le Conseil d’administration de l’ICANN.

(v) Pour que le panel d'arbitres approuve les propositions d’amendements des révisions proposées soit de l'ICANN, soit du Groupe de travail, le panel d'arbitres doit arriver à la conclusion que ces propositions d’amendements répondent à une application équilibrée des valeurs fondamentales de l'ICANN (telles que décrites dans les statuts constitutifs de l'ICANN) et sont raisonnables en termes d'équilibre entre les coûts et les bénéfices commerciaux des opérateurs de registre concernés et de l’ICANN (selon le cas), et l'intérêt public poursuivi par les révisions proposées tel qu’indiqué dans lesdites propositions d’amendements. Si le panel d'arbitres arrive à la conclusion que les propositions d’amendements des révisions proposées soit de l'ICANN, soit du Groupe de travail répondent aux critères susmentionnés, ces amendements entreront en vigueur et seront réputés constituer des amendements du présent contrat à l’issue d’un délai de soixante (60) jours civils à compter de l’avis envoyé par l'ICANN à l’opérateur de registre et seront réputés constituer un amendement approuvé en vertu des présentes.

(f) En ce qui concerne un amendement approuvé relatif à une

proposition d’amendement de l’ICANN, le registre pourra faire une demande écrite à

l’ICANN d’exemption audit amendement, conformément aux dispositions de l’article 7.6.

(g) Nonobstant toute disposition contraire du présent article 7.7, (a) si l’opérateur de registre démontre, à la satisfaction raisonnable de l’ICANN, que l’amendement approuvé augmenterait considérablement le coût de la fourniture des services de registre, l’ICANN accordera un délai maximum de cent quatre-vingts (180)

jours civils pour l’entrée en vigueur de l’amendement approuvé à l’égard de l’opérateur de registre, et (ii) aucun amendement approuvé conformément à l’article 7.7 n’entrera en vigueur à l’égard de l’opérateur de registre si l’opérateur de registre présente à l’ICANN un avis irrévocable de résiliation conformément à l’article 4.4(b).

7.8 Absence de tiers bénéficiaires. Le présent contrat ne doit pas être

interprété de façon à ce que l’ICANN ou l’opérateur de registre puisse imposer des

obligations à des personnes qui ne sont pas parties au présent contrat, y compris les

titulaires de noms enregistrés ou les bureaux d’enregistrement.

7.9 Notifications générales. Sauf pour les notifications relevant des articles 7.6 et 7.7, toutes les notifications à remettre dans le cadre du présent Contrat ou liées à ce

dernier, seront remises soit (i) par écrit à l’adresse de la partie concernée comme indiqué

ci-dessous, soit (ii) par courrier électronique, comme spécifié ci-dessous, sauf si cette partie a signalé un changement d’adresse postale ou électronique, tel qu’indiqué dans le présent Contrat. Toutes les notifications relevant des articles 7.6 et 7.7 seront effectuées en affichant les informations en question sur le site web de l’ICANN en plus de transmettre lesdites informations par courrier électronique à l’Opérateur de registre. Toute modification apportée aux coordonnées à des fins de notification sera apportée par la partie concernée dans un délai de trente (30) jours civils à compter de ladite modification. Sauf pour les notifications relevant des articles 7.6 ou 7.7, toutes les notifications exigées par le présent Contrat seront réputées avoir été correctement transmises (i) soit en

support papier lorsqu’elles sont remises en mains propres ou via un service de courrier avec accusé de réception, (ii) soit par courrier électronique sur confirmation de la réception par le serveur de messagerie du destinataire, à condition que cet envoi par

courrier électronique soit suivi de l’envoi d’une copie par la poste dans un délai de trois (3) jours civils. Toute notification requise en vertu des articles 7.6 et 7.7 sera réputée avoir été transmise une fois publiée sur le site web de l’ICANN ou sur confirmation de la réception par le serveur de messagerie. Dans l’hypothèse où d’autres moyens de notification pourraient être envisagés, comme une notification via un site web sécurisé, les parties travailleront ensemble afin de mettre en œuvre ces moyens de notification dans le cadre du présent Contrat.

Pour l’ICANN, les notifications seront envoyées à : Internet Corporation for Assigned Names and Numbers 00000 Xxxxxxxxxx Xxxxx, Xxxxx 000

Xxx Xxxxxxx, XX 00000-0000 Xxxxx-Xxxx

Téléphone : x0-000-000-0000

À l’attention du : Président-directeur général

Avec une copie obligatoire pour le : Conseiller juridique E-mail : (tel qu'occasionnellement indiqué.)

Pour l’opérateur de registre, les notifications seront envoyées à : [      ]

[       ]

[       ]

Téléphone :

Avec une copie obligatoire pour :

E-mail : (tel qu'occasionnellement indiqué.)

7.10 Intégralité du contrat. Le présent contrat (y compris les spécifications et les documents intégrés par renvoi aux emplacements URL qui font partie de celui-ci) constitue l’intégralité du contrat des parties en rapport avec l'exploitation du TLD et remplace tous les contrats et arrangements conclus préalablement ainsi que les négociations et discussions menées préalablement, à l’écrit ou à l’oral, entre les parties sur ce sujet.

7.11 Primauté de la version anglaise. En dépit de toute version traduite du

présent contrat et/ou des spécifications susceptible d’être fournie à l’opérateur de registre, la version anglaise du présent contrat et de toutes les spécifications mentionnées constitue la version officielle qui lie les parties concernées. En cas de conflit ou de divergence entre une version traduite du présent contrat et la version anglaise, cette dernière prévaudra. Les notifications, désignations, décisions et spécifications relevant du présent contrat seront en anglais.

7.12 Droits de propriété. Aucune disposition du présent contrat ne sera

interprétée comme (a) établissant ou accordant à l’opérateur de registre des droits de propriété ou intérêts relatifs au TLD ou aux lettres, mots, symboles ou autres caractères composant la chaîne du TLD, ou (b) portant atteinte aux droits de propriété intellectuelle ou de propriété existants de l’opérateur de registre.

7.13 Divisibilité ; conflits avec les lois. Le présent contrat sera réputé divisible ; l’invalidité ou l’inapplicabilité d’une condition ou d’une disposition du présent contrat n’aura pas d’incidence sur la validité et l’applicabilité du reste du présent contrat ou de toute autre condition de ce dernier, le présent contrat restant pleinement en vigueur. Si l’une quelconque des dispositions du présent Contrat est jugée invalide ou inapplicable, les parties négocieront en toute bonne foi la modification du présent Contrat de sorte à refléter autant que possible l’intention originelle des parties. L’ICANN et le Groupe de travail coopéreront pour élaborer une procédure d’examen par l’ICANN de conflits présumés entre les lois applicables et les dispositions du présent contrat non liées au RDDS (tel que défini à la spécification 4). Jusqu'à ce qu’une telle procédure soit élaborée et mise en œuvre par l'ICANN, l'ICANN examinera les conflits présumés entre les lois applicables et les dispositions du présent Contrat non liées au RDDS en suivant une démarche similaire à la procédure prévue par l'ICANN pour gérer les conflits entre le WHOIS et les lois en matière de confidentialité.

7.14 Décisions de justice. L’ICANN respectera toute décision prise par un tribunal compétent, y compris les décisions prises par tout tribunal où le consentement ou l’absence d’objection du gouvernement constituait une condition à la délégation du TLD. Nonobstant toute autre disposition du présent contrat, la mise en œuvre par l’ICANN d’une telle décision ne constituera pas une violation du présent contrat.

7.15 Confidentialité

(a) Sous réserve de l’ article 7.15(c), pendant toute la durée du présent contrat et pendant une période de trois (3) ans par la suite, chaque partie devra garantir et ne pas publier ou divulguer à des tiers, et devra faire en sorte que ses dirigeants, administrateurs, employés et agents et ceux de ses sociétés affiliés garantissent la confidentialité et ne publient ou divulguent pas à des tiers, directement ou indirectement,

toute information étant, ou toute information que la partie divulgatrice a qualifiée de ou a désignée par écrit à la partie destinataire comme étant un « secret commercial confidentiel », une « information commerciale confidentielle » ou une « information financière confidentielle » (collectivement, les « Informations confidentielles »), sauf dans la mesure où une telle divulgation est autorisée par les dispositions du présent contrat.

(b) Les obligations de confidentialité prévues à l’article 7.15(a) ne s’appliqueront pas aux informations confidentielles qui (i) relèvent du ou tomberont dans le domaine public par l’usage public, la publication, les connaissances générales ou similaire sans aucune faute de la partie destinataire en violation du présent contrat, (ii) dont on peut prouver par des documents ou autres preuves admissibles qu’elles ont été en possession de la partie destinataire avant la divulgation par la partie divulgatrice sans aucune obligation de confidentialité à l’égard de ces informations, (iii) sont ensuite envoyées à la partie destinataire par un tiers qui n’est pas lié par une obligation de confidentialité à l’égard de ces informations, (iv) ont été publiées par un tiers ou tombe dans le domaine public sans aucune faute de la partie destinataire, ou (v) dont on peut

prouver par des documents ou autres preuves admissibles qu’elles ont été développées indépendamment par ou pour la partie destinataire sans référence à des informations confidentielles de la partie divulgatrice.

(c) Chaque partie a le droit de divulguer des informations confidentielles si une telle divulgation est (i) effectuée en réponse à une décision valide d’un tribunal compétent ou, si de l’avis raisonnable de l’avocat de la partie destinataire, cette divulgation est requise par la loi applicable, à condition, toutefois, que la partie destinataire en ait préalablement informé la partie divulgatrice via un avis et lui ait donné la possibilité, dans la mesure du raisonnable, de faire annuler une telle décision ou d’obtenir un ordre de protection ou un ordre de traitement confidentiel exigeant que les informations confidentielles faisant l’objet d’un tel ordre ou de toute autre loi applicable soient traitées en toute confidentialité par ce tribunal ou un autre destinataire tiers, à moins que la partie destinataire ne soit pas autorisée à fournir un tel avis en vertu d’un tel ordre ou d’une loi applicable, ou (ii) effectuée par la partie destinataire ou l’une de ses sociétés affiliées à ses avocats, auditeurs, conseillers, consultants, entrepreneurs ou autres tiers à des fins d’utilisation par ladite personne ou entité tel que cela pourrait s’avérer nécessaire ou utile dans le cadre de l’exécution des activités en vertu du présent contrat, à condition que ledit tiers soit lié par des obligations de confidentialité au moins aussi strictes que celles prévues dans les présentes, que ce soit via un accord écrit ou du fait de normes de responsabilité professionnelle.

[Remarque : l’article suivant est uniquement applicable aux organisations

intergouvernementales ou entités gouvernementales].

7.16 Disposition spéciale relative aux organisations intergouvernementales ou aux entités gouvernementales.

(a) L’ICANN reconnaît que l’opérateur de registre est une entité soumise

au droit international public, y compris aux traités internationaux applicables à l’opérateur

de registre (le droit international public et ces traités étant ci-après collectivement désignés la « législation applicable »). Rien dans le présent contrat et dans les spécifications associées à celui-ci ne peut être interprété comme exigeant à l’opérateur de registre de violer la législation applicable ou d’empêcher le respect de celle-ci. Les parties conviennent que le respect de la Législation applicable par l’opérateur de registre ne doit pas constituer un manquement au présent contrat.

(b) Si l’opérateur de registre établit, dans la mesure du raisonnable, que toute disposition du présent contrat et des spécifications y afférentes, ou toute décision ou politique de l’ICANN mentionnée dans le présent contrat, y compris, mais sans s’y limiter, les politiques temporaires ou les politiques de consensus (de telles dispositions, spécifications et politiques étant ci-après collectivement désignées les « exigences de

l’ICANN »), peuvent entrer en conflit avec ou violer la législation applicable (ci-après, un

« Conflit potentiel »), l’opérateur de registre doit informer l’ICANN, via un avis détaillé (ci- après un « Avis »), d’un tel conflit potentiel dans les plus brefs délais et, dans le cas d’un conflit potentiel avec une politique de consensus proposée, au plus tard à la fin de toute période de consultation publique sur ladite politique de consensus proposée. Si l’opérateur de registre établit qu’il existe un conflit potentiel entre une législation applicable proposée et une exigence de l’ICANN, l’opérateur de registre doit informer l’ICANN, via un avis détaillé, d’un tel conflit potentiel dans les plus brefs délais et, en cas de conflit potentiel avec une politique de consensus proposée, au plus tard à la fin de toute période de consultation publique sur ladite politique de consensus proposée.

(c) Dès que possible après un tel examen, les parties tenteront de régler le conflit potentiel via une médiation, conformément aux procédures établies à l’article 5.1. En outre, l’opérateur de registre fera de son mieux pour supprimer ou minimiser tout impact découlant d’un tel conflit potentiel entre la législation applicable et une exigence de l’ICANN. Si, suite à cette médiation, l’opérateur de registre établit que le conflit potentiel constitue un conflit réel entre une exigence de l’ICANN, d’une part, et la législation applicable, d’autre part, l’ICANN devra renoncer au respect d’une telle exigence de l’ICANN (sous réserve que les parties négocient en toute bonne foi et de façon continue par la suite afin d’atténuer ou de supprimer les effets d’un tel non-respect sur l’ICANN), sauf si l’ICANN établit, de façon raisonnable et objective, que le non-respect par l’opérateur de registre d’une telle exigence de l’ICANN constituerait une menace à la sécurité et à la stabilité des services de registre, d’Internet ou du DNS (ci-après, les « Conclusions de l’ICANN »). Suite à la réception, par l’opérateur de registre, de l’avis informant de telles conclusions de

l’ICANN, l’opérateur de registre disposera d’une période de quatre-vingt-dix (90) jours civils pour régler un tel conflit avec la législation applicable. Si le conflit avec la législation applicable n’est pas réglé à l’entière satisfaction de l’ICANN au cours de cette période, l’opérateur de registre aura la possibilité de soumettre l’affaire à un arbitrage exécutoire tel que défini au sous-paragraphe (d) ci-dessous, dans un délai de dix (10) jours. Si, dans ce délai, l’opérateur de registre ne soumet pas l’affaire à un arbitrage conformément au sous- paragraphe (d) ci-dessous, l’ICANN pourra, après en avoir informé l’opérateur de registre, résilier le présent contrat, cette résiliation entrant immédiatement en vigueur.

(d) Si l’opérateur de registre est en désaccord avec les conclusions de l’ICANN, il pourra soumettre l’affaire à un arbitrage exécutoire conformément aux dispositions de l’article 5.2, sauf si la seule question présentée à l’arbitre pour que celui-ci tranche est de savoir si lesdites conclusions de l’ICANN ont été dégagées de façon

raisonnable et objective. Aux fins d’un tel arbitrage, l’ICANN devra présenter à l’arbitre des preuves soutenant les conclusions de l’ICANN. Si l’arbitre établit que les conclusions de l’ICANN n’ont pas été dégagées de façon raisonnable et objective, l’ICANN devra renoncer au respect de l’exigence de l’ICANN en question par l’opérateur de registre. Si les arbitres ou l’arbitre intervenant dans le cadre d’une procédure de référé préarbitral, selon le cas, établissent que les conclusions de l’ICANN ont été dégagées de façon raisonnable et

objective, l’ICANN pourra, après en avoir informé l’opérateur de registre, résilier le présent

contrat, cette résiliation entrant immédiatement en vigueur.

(e) Par les présentes, l’opérateur de registre déclare et garantit qu’à sa connaissance, à la date d’exécution du présent contrat, aucune exigence de l’ICANN existante n’entre en conflit avec la législation applicable ou ne viole cette dernière.

(f) Nonobstant toute autre disposition du présent article 7.16, à la suite des conclusions de l’ICANN et avant la décision d’un arbitre conformément à l’article 7.16(d) ci-dessus, l’ICANN pourra, sous réserve d’avoir consulté au préalable l’opérateur de registre, prendre les mesures techniques raisonnables qu’elle jugera nécessaires pour

garantir la sécurité et la stabilité des services de registre, d’Internet et du DNS. Lesdites mesures techniques raisonnables seront prises par l’ICANN à titre temporaire, jusqu’à la date de conclusion de la procédure d’arbitrage mentionnée à l’article 7.16(d) ci-dessus ou la date de règlement intégral du conflit avec la législation applicable, la première de ces deux éventualités étant retenue. Si l’opérateur de registre est en désaccord avec les mesures techniques prises par l’ICANN, il pourra soumettre l’affaire à un arbitrage exécutoire conformément aux dispositions de l’article 5.2 ci-dessus, étant entendu que pendant la durée de l’arbitrage, l’ICANN pourra continuer à appliquer lesdites mesures

techniques. Si l’ICANN prend de telles mesures, l’opérateur de registre devra payer tous les frais engagés par l’ICANN du fait de telles mesures. En outre, si l’ICANN prend de telles mesures, l’ICANN conservera et pourra faire valoir ses droits en vertu de l’instrument assurant la continuité des opérations et de l’instrument alternatif, selon le cas.

* * * * *

EN FOI DE QUOI, les représentants dûment autorisés des parties ont signé le présent contrat.

SOCIÉTÉ POUR L’ATTRIBUTION DES NOMS DE DOMAINE ET DES NUMÉROS

SUR INTERNET

Par :          [      ]

Président-directeur général Date :

[Opérateur de registre]

Par :          [      ]

[     ] Date :

ANNEXE A

Services approuvés

Le guide de candidature aux gTLD de l’ICANN (disponible sur

xxxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxx/xxx) et la politique d’évaluation des services de registre (RSEP) précisent les processus d’examen des services de registre proposés.

L’opérateur de registre peut fournir tout service requis par les dispositions du présent contrat. En outre, les services suivants (le cas échéant) sont spécifiquement identifiés comme ayant été approuvés par l'ICANN avant la date d’entrée en vigueur du Contrat, et l'Opérateur de registre peut fournir de tels services :

1. Service DNS – Contenus de la zone TLD

Nonobstant toute autre disposition du présent contrat, tel qu’indiqué à l’article 2.2.3.3 du guide de candidature aux gTLD, les contenus admissibles pour le service DNS de TLD sont les suivants :

1.1. Pour la classe « Internet » (IN) :

1.1.1. Enregistrement Apex SOA.

1.1.2. Enregistrements Apex NS et colle in-bailiwick pour les serveurs DNS de TLD.

1.1.3. Enregistrements NS et colle in-bailiwick pour les serveurs DNS des noms enregistrés dans le TLD.

1.1.4. Enregistrements DS pour les noms enregistrés dans le TLD.

1.1.5. Enregistrements associés à la signature de la zone TLD (par exemple, XXXXX, XXXXXX, XXXX, XXXX0XXXXX et NSEC3).

1.1.6. Enregistrement Apex TXT pour l’identification des versions de la zone.

1.1.7. Enregistrement Apex TYPE65534 pour la signalisation de la signature automatique des DNSSEC.

1.2. Pour la classe « Chaos » (CH) :

1.2.1. Enregistrements TXT pour la version/l’identification du serveur (par exemple, les enregistrements TXT pour « version.bind. », « id.server. », « authors.bind » et/ou

« hostname.bind. »).

(Remarque : La disposition ci-dessus ne permet pas, entre autres, l’inclusion des

enregistrements de ressources DNS qui permettrait l’existence d’un nom de domaine sans

point (par exemple, apex A, AAAA, enregistrements MX) dans la zone TLD).

Si l’opérateur de registre souhaite placer tout type ou classe d’enregistrement de ressource DNS dans son service DNS de TLD (autres que ceux énumérés aux articles 1.1 ou 1.2 ci- dessus), il doit décrire en détail sa proposition et soumettre une demande de processus d’évaluation des services de registre (RSEP). Cette proposition sera évaluée conformément au RSEP pour déterminer si le service pourrait comporter un risque d’effet négatif important sur la sécurité ou la stabilité du DNS. L’opérateur de registre reconnaît et admet qu’un service basé sur l’utilisation d’enregistrements de ressource DNS et/ou de classes peu communs dans la zone TLD, même autorisés, peut ne pas fonctionner comme prévu pour tous les utilisateurs en raison d’un manque de soutien logiciel.

SPÉCIFICATION 1

SPÉCIFICATION RELATIVE AUX POLITIQUES DE CONSENSUS ET AUX POLITIQUES TEMPORAIRES

1. Politiques de consensus :

1.1. Les « politiques de consensus » sont les politiques (1) établies conformément à la procédure définie dans les statuts constitutifs de l’ICANN et à la loi, et (2) portant sur les questions énoncées dans l’article 1.2 de la présente spécification. Le processus et la procédure d’élaboration des politiques de consensus établis dans les statuts constitutifs de l’ICANN peuvent occasionnellement être révisés conformément à la procédure définie dans les présentes.

1.2. Les politiques de consensus et les procédures régissant leur élaboration seront conçues de sorte à dégager, dans la mesure du possible, un consensus des parties prenantes de l’Internet, notamment des opérateurs de gTLD. Les politiques de consensus concerneront l’une ou plusieurs des questions suivantes :

1.2.1 les questions pour lesquelles une résolution uniforme ou coordonnée est raisonnablement requise pour faciliter l’interopérabilité, la

sécurité et/ou la stabilité de l’Internet ou du système des noms de

domaine (« DNS ») ;

1.2.2 les spécifications fonctionnelles et relatives aux performances pour la fourniture des services de registre ;

1.2.3 la sécurité et la stabilité de la base de données des registres pour le TLD ;

1.2.4 les politiques de registre raisonnablement requises pour mettre en

œuvre les politiques de consensus relatives aux opérations des registres ou des bureaux d’enregistrement ;

1.2.5 le règlement des litiges relatifs à l’enregistrement des noms de

domaine (et non à l’utilisation de ces noms de domaine) ; ou

1.2.6 les restrictions à la propriété hybride des opérateurs de registre et

des bureaux d’enregistrement ou des revendeurs des bureaux

d’enregistrement, les règlementations et restrictions par rapport aux opérations des registres et à l’utilisation des données des opérateurs de registre et des bureaux d’enregistrement dans l’hypothèse où un opérateur de registre et un bureau d’enregistrement ou un revendeur de bureau d’enregistrement seraient affiliés.

1.3. Ces catégories de questions mentionnées dans l’article 1.2 de la présente spécification incluront, sans s’y limiter :

1.3.1 les principes gouvernant l’attribution des noms enregistrés dans le

TLD (par exemple, premier arrivé-premier servi, renouvellement

rapide, période d’attente après l’expiration) ;

1.3.2 les interdictions concernant le stockage ou la spéculation sur les noms

de domaine par les registres ou les bureaux d’enregistrement ;

1.3.3 la réservation de noms enregistrés dans le TLD qui ne peuvent faire l’objet d’un enregistrement initial ou ne peuvent être renouvelés en raison de motifs raisonnablement liés (a) à la nécessité d’éviter toute

confusion des utilisateurs et de les induire en erreur, (b) à la propriété intellectuelle ou (c) à la gestion technique du DNS ou de l’Internet (par exemple, établissement de noms réservés à l’enregistrement) ; et

1.3.4 la conservation d’informations exactes et à jour sur les

enregistrements de noms de domaine, et l’accès à celles-ci, et les procédures pour éviter les interruptions dans les enregistrements de noms de domaine dues à la suspension ou à la cessation définitive des opérations par un opérateur de registre ou un bureau

d’enregistrement, y compris les procédures pour l’attribution de la responsabilité pour le service de noms de domaine enregistrés dans un TLD affecté par une telle suspension ou cessation.

1.4. Outre les autres limitations relatives aux politiques de consensus, elles respecteront également les impératifs suivants :

1.4.1 ne pas prescrire ou limiter le prix des services de registre ;

1.4.2 ne pas modifier les conditions générales relatives au renouvellement ou à la résiliation du contrat de registre ;

1.4.3 ne pas modifier les limitations relatives aux politiques temporaires (définies ci-dessous) ou aux politiques de consensus ;

1.4.4 ne pas modifier les dispositions du contrat de registre concernant les

frais versés par l’opérateur de registre à l’ICANN ; ou

1.4.5 ne pas modifier les obligations de l’ICANN d’assurer un traitement équitable des opérateurs de registre et d’agir de façon ouverte et transparente.

2. Politiques temporaires. L’opérateur de registre s’engage à respecter et mettre en œuvre toutes les spécifications ou politiques établies par le Conseil d’administration de l’ICANN à titre temporaire, si celles-ci ont été adoptées par le Conseil

d’administration par le vote d’au moins deux tiers de ses membres, dans la mesure où le Conseil d’administration détermine raisonnablement que de telles modifications ou de tels amendements sont justifiés, et que l’établissement temporaire immédiat d’une spécification ou d’une politique sur cette question est nécessaire pour maintenir la stabilité ou la sécurité des services de registre ou du DNS (les « Politiques temporaires »).

2.1. Cette proposition de spécification ou de politique devra être strictement adaptée de sorte à atteindre ces objectifs. Lors de l’établissement de toute politique temporaire, le Conseil d’administration définira la période pour laquelle cette politique temporaire est adoptée et mettra immédiatement en œuvre le processus d’élaboration de politiques de consensus prévu dans les statuts constitutifs de l’ICANN.

2.1.1 L’ICANN émettra également une déclaration consultative contenant une explication détaillée des motifs pour lesquels elle adopte la politique temporaire et des raisons pour lesquelles le Conseil d’administration estime que cette politique temporaire doit faire consensus parmi les parties prenantes d’Internet.

2.1.2 Si la période pour laquelle la politique temporaire est adoptée dépasse les quatre-vingt-dix (90) jours civils, le Conseil

d’administration réitérera son adoption temporaire tous les quatre- vingt-dix (90) jours civils pendant une période totale ne pouvant dépasser un (1) an, afin de maintenir en vigueur ladite politique temporaire jusqu’à ce qu’elle devienne une politique de consensus. Si la période d’un (1) an expire ou si, durant cette période d’un (1) an, la politique temporaire ne devient pas une politique de consensus et que son adoption n’est pas réitérée par le Conseil d’administration,

l’opérateur de registre ne sera plus tenu de respecter ni de mettre en œuvre cette politique temporaire.

3. Avis et conflits. Suite à l’avis d’établissement d’une politique de consensus ou d’une politique temporaire, l’opérateur de registre se verra accorder un délai raisonnable pour se conformer à ladite politique ou spécification, en tenant compte de toute éventuelle urgence. En cas de conflit entre des services de registre et des politiques de consensus ou une politique temporaire, les politiques de consensus ou la politique temporaire prévaudront, mais uniquement en ce qui concerne l’objet du conflit.

SPÉCIFICATION 2

CONDITIONS DE L’ENTIERCEMENT DE DONNÉES

L’opérateur de registre engagera une entité indépendante qui agira en tant qu’agent d’entiercement de données (l’« Agent d’entiercement ») et fournira des services d’entiercement de données liés au contrat de registre. Les spécifications techniques suivantes établies dans la partie A et les exigences légales établies dans la partie B seront

incluses dans tout contrat d’entiercement de données conclu entre l’opérateur de registre et l’agent d’entiercement en vertu duquel l’ICANN doit être nommée tiers bénéficiaire.

Outre les exigences suivantes, le contrat d’entiercement de données peut contenir d’autres dispositions qui ne sont ni contradictoires ni destinées à contourner les conditions obligatoires définies ci-dessous.

PARTIE A – SPÉCIFICATIONS TECHNIQUES

1. Dépôts. Il existe deux types de dépôt : le dépôt complet et le dépôt différentiel. Quel que soit le type de dépôt, les éléments de registres à prendre en compte pour l’entiercement de données sont les éléments nécessaires pour proposer l’ensemble des services de registre approuvés.

1.1. Le « dépôt complet » sera composé de données qui reflètent l’état du registre à 00 h 00 UTC (temps universel coordonné) le jour où ledit dépôt complet est soumis à l’agent d’entiercement.

1.2. Le « dépôt différentiel » fait référence aux données qui reflètent toutes les transactions n’ayant pas été prises en compte dans le dernier dépôt complet ou différentiel, selon le cas. Chaque dépôt différentiel contiendra toutes les transactions de base de données depuis le dépôt précédent, à 00 h 00 UTC tous les jours, sauf le dimanche. Le dépôt différentiel doit inclure les

enregistrements de dépôt complets, tel qu’indiqué ci-dessous, n’ayant pas été inclus ou modifiés depuis le dernier dépôt complet ou différentiel (c’est-à- dire les ajouts, modifications ou annulations de données).

2. Planification des dépôts. L’opérateur de registre enverra quotidiennement un

ensemble de fichiers de dépôt selon les modalités suivantes :

2.1. Chaque dimanche, un dépôt complet devra être envoyé à l’agent d’entiercement au plus tard à 23 h 59 UTC.

2.2. Xxx xxx (6) autres jours de la semaine, le dépôt complet ou le dépôt

différentiel correspondant devra être envoyé à l’agent d’entiercement au plus

tard à 23 h 59 UTC.

3. Spécification relative au format des dépôts.

3.1. Format des dépôts. Les éléments de registres, tels que les domaines, les contacts, les serveurs de noms, les bureaux d'enregistrement, etc. seront compilés dans un fichier construit comme décrit dans la norme RFC 8909, voir la partie A, article 9, référence 1 de la présente spécification, et la norme RFC 9022, voir la partie A, article 9, référence 2 de la présente spécification (collectivement, la « Spécification DNDE »). La Spécification DNDE qualifie certains éléments de facultatifs ; l’Opérateur de registre inclura ces éléments dans les Dépôts s’ils sont disponibles. Le codage de caractères UTF-8 sera utilisé.

3.2. Extensions. Si un opérateur de registre propose des services de registre supplémentaires qui nécessitent l’envoi de données complémentaires, non incluses ci-dessus, il conviendra de définir d’autres « schémas d’extension » au cas par cas pour représenter ces données. Ces « schémas d’extension » seront spécifiés comme décrit dans la partie A, article 9, référence 2 de la présente spécification. Les données relatives aux « schémas d’extension » seront comprises dans le fichier de dépôt décrit dans la partie A, article 3.1 de la présente spécification. L’ICANN et l’opérateur de registre correspondant travailleront en collaboration pour convenir des spécifications relatives à l’entiercement de données de ces nouveaux éléments.

4. Traitement des fichiers de dépôt. Il est conseillé de recourir à la compression pour réduire la durée des transferts de données électroniques et les exigences en matière de capacité de stockage. L’encodage des données sera utilisé pour garantir la confidentialité des données déposées du registre. Les fichiers traités à des fins de compression et d’encodage doivent être au format OpenPGP binaire, conformément au format de message OpenPGP de la norme RFC 4880, voir partie A, article 9, référence 3 de la présente spécification. Les algorithmes acceptables pour le chiffrement à clé publique, le chiffrement à clé symétrique, le hachage et la

compression sont ceux répertoriés dans la norme RFC 4880, sous réserve qu’ils ne soient pas qualifiés d’obsolètes dans le registre OpenPGP de l’IANA, voir partie A,

article 9, référence 4 de la présente spécification, et qu’ils soient également libres de

droits. Voici la marche à suivre pour un fichier de données en format texte

d’origine :

(1) Le fichier XML du dépôt tel que décrit dans la partie A, article 9, référence 1 de la présente spécification doit être désigné comme étant le fichier de contention tel que spécifié dans l’article 5, mais avec l’extension xml.

(2) Les fichiers de zone sont regroupés dans un fichier tarball nommé comme au

point (1), mais avec l’extension tar.

(3) Un message OpenPGP comprimé et encodé est créé en utilisant le fichier tarball comme seule entrée. L’algorithme de compression suggéré est ZIP, conformément à la norme RFC 4880. Les données compressées doivent être

encodées au moyen de la clé publique de l’agent d’entiercement. Les algorithmes suggérés pour le chiffrage à clé publique sont Elgamal et RSA, conformément à la norme RFC 4880. Les algorithmes suggérés pour le chiffrage à clé symétrique sont TripleDES, AES128 et CAST5, conformément à la norme RFC 4880.

(4) Le fichier peut être divisé en plusieurs parties si, une fois compressé et

chiffré, sa taille est supérieure à la limite convenue avec l’agent

d’entiercement. Dans le présent article, chaque partie d’un fichier divisé, ou l’intégralité du fichier s’il n’est pas divisé, est appelé un fichier traité.

(5) Un fichier de signature numérique sera créé pour chaque fichier traité au moyen de la clé privée de l’opérateur de registre. Le fichier de signature numérique doit être au format OpenPGP binaire, conformément à la norme RFC 4880, article 9, référence 3, et ne doit être ni compressé, ni chiffré. Les algorithmes suggérés de signature numérique sont DSA et RSA, conformément à la norme RFC 4880. L’algorithme suggéré pour le hachage des signatures numériques est SHA256.

(6) Les fichiers traités et les fichiers de signature numérique seront alors transférés à l’agent d’entiercement via des mécanismes électroniques sécurisés, tels que SFTP, SCP, HTTPS, etc., comme convenu entre l’agent d’entiercement et l’opérateur de registre. La livraison via un support physique, comme les CD-ROM, les DVD-ROM ou les périphériques de stockage USB, est possible à condition que l’ICANN l’autorise.

(7) L’agent d’entiercement valide ensuite chaque fichier de données transféré (traité) conformément à la procédure décrite dans la partie A, article 8 de la présente spécification.

5. Conventions de dénomination des fichiers. Les fichiers seront nommés d’après la

convention suivante : {gTLD}_{AAAA-MM-JJ}_{type}_S{#}_R{rev}.{ext} où :

5.1. {gTLD} est remplacé par le nom gTLD ; en cas d’IDN-TLD, le format compatible ASCII (étiquette A) doit être utilisé ;

5.2. {AAAA-MM-JJ} est remplacé par la date correspondant à la date limite pour les transactions ; par exemple, pour le dépôt complet correspondant à 2009- 08-02T00:00Z, la chaîne doit être « 2009-08-02 » ;

5.3. {type} est remplacé par :

(1) « full », si les données représentent un dépôt complet ;

(2) « diff », si les données représentent un dépôt différentiel ;

(3) « résumé », si les données représentent un fichier d’accès groupé aux données d’enregistrement des noms de domaine, comme indiqué à la section 3 de la spécification 4 ;

(4) « détaillé-{gurid} », si les données représentent les données

d’enregistrement détaillé d’un bureau d’enregistrement spécifique, tel que défini à l’article 3.2 de la spécification 4. L’élément {gurid} doit être remplacé par l’ID du bureau d’enregistrement de l’IANA associé aux données.

5.4. {#} est remplacé par la position du fichier dans une série de fichiers, en commençant par « 1 ». En cas de dépôt comportant un seul fichier, ce caractère doit être remplacé par « 1 ».

5.5. {rev} est remplacé par le nombre de révisions (ou renvois) du fichier, en commençant par « 0 »:

5.6. {.ext} est remplacé par « sig » s’il s’agit d’un fichier de signature numérique

du fichier quasi homonyme. Si tel n’est pas le cas, il est remplacé par « ryde ».

6. Distribution de clés publiques. L’opérateur de registre et l’agent d’entiercement doivent s’échanger leurs clés publiques par messagerie électronique à une adresse e-mail à préciser. Chaque partie doit confirmer la réception de la clé publique de l’autre partie par retour d’e-mail ; la partie qui a envoyé la clé doit ensuite

reconfirmer l’authenticité de la clé transmise, au moyen d’une méthode hors ligne, par exemple une rencontre en personne, une conversation téléphonique, etc. Ainsi, la transmission de la clé publique est authentifiée par un utilisateur capable d’envoyer et de recevoir un e-mail via le serveur de messagerie exploité par la partie qui a effectué l’envoi. L’agent d’entiercement, l’opérateur de registre et l’ICANN doivent utiliser la même procédure pour échanger leurs clés publiques.

7. Notification des dépôts. Lors de la remise de chaque dépôt, l’opérateur de registre fournira à l’agent d’entiercement et à l’ICANN (en utilisant l’API décrite dans draft- lozano-icann-registry-interfaces, voir partie A, article 9, référence 5 de la présente spécification (la « Spécification relative à l’interface »)) une déclaration écrite de l’opérateur de registre (éventuellement par un message électronique authentifié) incluant une copie du rapport généré lors de la création du dépôt et stipulant que le dépôt a été inspecté par l’opérateur de registre et qu’il est complet et exact. La préparation et la présentation de cette déclaration doivent être effectuées par l'opérateur de registre ou son représentant, à condition que ce représentant ne soit pas l’agent d’entiercement ou l’une des sociétés affiliées de l’agent d’entiercement. L’opérateur de registre inclura les attributs « id » et « resend » du dépôt dans sa déclaration. Les attributs sont expliqués dans la partie A, article 9, référence 1 de la présente spécification.

Si ce n’est pas déjà une norme RFC, l’opérateur de registre utilisera la version la plus récente de la spécification relative à l’interface à la date d’entrée en vigueur.

L’opérateur de registre peut, s’il le souhaite, utiliser les versions plus récentes de la

spécification relative à l’interface après la date d’entrée en vigueur. Une fois que la spécification relative à l’interface est publiée en tant que norme RFC, l’opérateur de registre mettra en œuvre cette version de la spécification relative à l’interface, au plus tard cent quatre-vingts (180) jours civils après cette publication.

8. Procédure de vérification.

(1) Le fichier de signature de chaque fichier traité est validé.

(2) Si les fichiers traités constituent autant de parties d’un fichier plus grand, ces

parties sont rassemblées en un document unique.

(3) Chaque fichier obtenu à l’étape précédente est ensuite déchiffré et

décompressé.

(4) Chaque fichier de données contenu à l’étape précédente est ensuite validé, selon le format défini dans la partie A, article 9, référence 1 de la présente spécification.

(5) L’agent d’entiercement de données a étendu le processus de vérification, tel que défini ci- dessous dans la référence 2 de la partie A de la présente spécification, ainsi que tout autre processus de vérification d’entiercement de données contenu dans ladite référence.

En cas de divergence constatée à l’une de ces étapes, le dépôt sera considéré comme

incomplet.

9. Références.

(1) Spécification relative à l'entiercement de données d’enregistrement,

xxxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx

(2) Mappage d’éléments des données d'enregistrement de nom de domaine

(DNRD), xxxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx

(3) Format de message OpenPGP, xxxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx

(4) Paramètres OpenPGP,

xxxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxx-xxxxxxxxxx/xxx-xxxxxxxxxx.xxxxx

(5) Interfaces de registre de l’ICANN, xxxxx://xxxxxxxxxxx.xxxx.xxx/xxx/xxxxx- lozano-icann-registry-interfaces

PARTIE B – EXIGENCES LÉGALES

1. Agent d’entiercement. Avant de conclure un contrat d’entiercement, l’opérateur de registre doit informer l’ICANN de l’identité de l’agent d’entiercement et lui fournir ses coordonnées et une copie du contrat d’entiercement concerné, ainsi que de tous ses amendements. De plus, avant de conclure un contrat d’entiercement, l’opérateur de registre doit obtenir le consentement de l’ICANN pour (a) utiliser l’agent

d’entiercement spécifié, et (b) signer le contrat d’entiercement xxxxxx. L’ICANN doit être expressément désignée comme tiers bénéficiaire du contrat d’entiercement.

L’ICANN se réserve le droit de refuser tout agent d’entiercement, tout contrat

d’entiercement ou tout amendement, à son entière discrétion.

2. Honoraires. L’opérateur de registre doit verser, ou faire verser en son nom, des honoraires directement à l’agent d’entiercement. Si l’opérateur de registre ne verse pas ces honoraires à la date ou aux dates prévues, l’agent d’entiercement enverra un avis écrit à l’ICANN l’informant de ce défaut de paiement et l’ICANN pourra payer les honoraires restant à verser dans un délai de quinze (15) jours civils à compter de la date de réception de l’avis écrit de l’agent d’entiercement. Une fois les honoraires

restant à verser payés par l’ICANN, l’ICANN disposera d’une créance de ce montant à l’égard de l’opérateur de registre. Celui-ci devra rembourser cette créance à l’ICANN ainsi que le versement d’honoraires suivant prévu dans le cadre du contrat de registre.

3. Propriété. L’opérateur de registre conservera à tout moment la propriété des dépôts pendant la durée du contrat de registre. Par la suite, l’opérateur de registre attribuera à l’ICANN les droits de propriété (y compris, le cas échéant, les droits de propriété intellectuelle) sur lesdits dépôts. Dans l’hypothèse où un dépôt serait

restitué à l’ICANN pendant la durée du contrat de registre, les droits de propriété intellectuelle détenus par l’opérateur de registre sur ledit dépôt seront automatiquement cédés à l’ICANN ou à une partie désignée par écrit par l’ICANN dans le cadre d’une licence non exclusive, permanente, irrévocable et libre de droits, pour toute utilisation liée à l’opération, la maintenance ou la transition du TLD.

4. Intégrité et confidentialité. L’agent d’entiercement sera tenu (i) de conserver et maintenir les dépôts dans une installation sécurisée, verrouillée, sans danger pour l’environnement, accessible uniquement aux représentants autorisés de l’agent d’entiercement, (ii) de protéger l’intégrité et la confidentialité des dépôts à l’aide de mesures commercialement raisonnables et (iii) de conserver et sauvegarder chaque dépôt pendant un (1) an. L’ICANN et l’opérateur de registre auront le droit d’inspecter les enregistrements concernés de l’agent d’entiercement après envoi d’un préavis raisonnable et durant les heures normales de travail. L’opérateur de

registre et l’ICANN auront le droit de désigner un auditeur tiers pour auditer occasionnellement le respect par l’agent d’entiercement des spécifications techniques et des exigences de maintenance de la présente spécification 2.

Dans l’hypothèse où l’agent d’entiercement recevrait une assignation à comparaître ou toute autre injonction provenant d’un tribunal ou d’une autre entité judiciaire

relative à la divulgation ou à la restitution des dépôts, l’agent d’entiercement en informera sans délai l’opérateur de registre et l’ICANN, sauf si la loi le lui interdit. Après avoir informé l’opérateur de registre et l’ICANN, l’agent d’entiercement leur accordera un délai suffisant pour contester ladite injonction, une telle contestation leur incombant, sous réserve, toutefois, que l’agent d’entiercement ne renonce pas à ses droits de présenter sa position en rapport à ladite injonction. L’agent

d’entiercement coopérera avec l’opérateur de registre ou l’ICANN afin de les soutenir dans leurs efforts visant à rejeter ou limiter ladite injonction, aux frais de la partie concernée. Toute partie requérant une assistance supplémentaire devra s’acquitter auprès de l’agent d’entiercement de frais standard ou tels qu’indiqués sur demande détaillée.

5. Copies. L’agent d’entiercement peut être autorisé à dupliquer tout dépôt afin de se

conformer aux conditions générales du contrat d’entiercement.

6. Restitution des dépôts. L’agent d’entiercement mettra à la disposition de l’ICANN ou de son représentant, sous vingt-quatre (24) heures et aux frais de l’opérateur de registre, tous les dépôts en sa possession à des fins de téléchargement (sauf stipulation contraire), dans l’hypothèse où il recevrait une demande de l’opérateur de registre à cet effet ou recevrait l’un des avis écrits suivants de l’ICANN stipulant que :

6.1. le contrat de registre a expiré sans être renouvelé ou a été résilié ; ou

6.2. l’ICANN n’a pas reçu d’avis de l’agent d’entiercement, comme décrit dans la partie B, articles 7.1 et 7.2 de la présente spécification, dans les cinq (5) jours civils à compter de la date prévue de réalisation du dépôt, (a) l’ICANN a

averti l’agent d’entiercement et l’opérateur de registre de cette situation, et

(b) l’ICANN n’a pas reçu, dans les sept (7) jours civils à compter de la réception de cet avis, l’avis de l’agent d’entiercement ; ou

6.3. l’ICANN a reçu l’avis de l’agent d’entiercement, de la manière décrite dans la partie B, articles 7.1 et 7.2 de la présente spécification, l’informant de l’absence de vérification du dernier dépôt à une date spécifique ou un avis l’informant d’un dépôt manquant, et l’avis concerne un dépôt qui aurait dû être réalisé le dimanche (c’est-à-dire un dépôt complet), (a) l’ICANN a averti l’opérateur de registre de la réception de cet avis, et (b) l’ICANN n’a pas reçu, dans les sept (7) jours civils à compter de la réception de cet avis, l’avis comme décrit dans la partie B, articles 7.1 et 7.2 de la présente spécification de la part de l’agent d’entiercement l’informant de la vérification d’une version corrigée de ce dépôt complet ; ou

6.4. l’ICANN a reçu cinq avis de l’agent d’entiercement dans les trente (30)

derniers jours civils l’informant des dépôts manquants ou défectueux qui

auraient dû être réalisés du lundi au samedi (c’est-à-dire un dépôt

différentiel), et (x) l’ICANN a informé l’opérateur de registre de la réception de ces avis, et (y) l’ICANN n’a pas reçu, dans les sept (7) jours civils à compter de l’envoi dudit avis à l’opérateur de registre, d’avis de l’agent d’entiercement l’informant de la vérification d’une version corrigée de ce dépôt différentiel ; ou

6.5. l’opérateur de registre : (i) a cessé de mener ses activités de manière normale ; ou (ii) a été déclaré en faillite, est devenu insolvable ou a été confronté à toute autre situation analogue en vertu des lois d’une juridiction du monde ; ou

6.6. l’opérateur de registre a été confronté à une défaillance de ses fonctions de

registre critiques et l’ICANN a exercé ses droits conformément à l’article 2.13

du contrat ; ou

6.7. un tribunal, une instance arbitrale, législative ou gouvernementale compétent(e) ordonne la restitution des dépôts à l’ICANN ; ou

6.8. en vertu d’audits de conformité contractuelle et opérationnelle comme spécifié dans l’article 2.11 du contrat.

Si l’agent d’entiercement n’a pas précédemment restitué les dépôts de l’opérateur de registre à l’ICANN ou à son représentant, l’agent d’entiercement restituera tous les dépôts à l’ICANN dès l’expiration ou la résiliation du contrat de registre ou du contrat d’entiercement.

7. Vérification des dépôts.

7.1. Dans un délai de vingt-quatre (24) heures à compter de la réception de chaque dépôt ou dépôt corrigé, l’agent d’entiercement doit vérifier le format et l’exhaustivité de chaque dépôt et fournir à l’ICANN un avis créé pour chaque dépôt. Les rapports seront remis par voie électronique en utilisant l’API décrite dans draft-lozano-icann-registry-interfaces, voir la partie A, article 9, référence 5 de la présente spécification.

7.2. Si l’agent d’entiercement découvre qu’un dépôt ne respecte pas les

procédures de vérification ou si l’agent d’entiercement ne reçoit aucun dépôt prévu, l’agent d’entiercement doit aviser l’opérateur de registre, par courriel, par télécopieur ou par téléphone, et l’ICANN (en utilisant l’API décrite dans draft-lozano-icann-registry-interfaces, voir la partie A, article 9, référence 5 de la présente spécification) de ce non-respect ou de la non-réception dans les vingt-quatre (24) heures à compter de la réception du dépôt non conforme ou de la date limite de ce dépôt, selon le cas. Dès la réception de l’avis informant de l’absence de vérification ou de réception du dépôt,

l’opérateur de registre doit commencer à procéder aux modifications, mises à jour et autres correctifs requis pour permettre au dépôt d’être réalisé et

soumis aux procédures de vérification et fournir ces correctifs à l’agent d’entiercement dans les meilleurs délais.

8. Amendements. L’agent d’entiercement et l’opérateur de registre amenderont les termes du contrat d’entiercement afin de respecter la présente spécification 2 dans les dix (10) jours civils suivant tout amendement ou toute modification de ladite spécification 2. En cas de conflit entre la présente spécification 2 et le contrat d’entiercement, la présente spécification 2 prévaudra.

9. Indemnisation. L’agent d’entiercement indemnisera et dégagera l’opérateur de registre et l’ICANN, ainsi que leurs directeurs, membres de la direction, agents, employés, membres et actionnaires respectifs (ci-après les « Indemnisés »), sans

restriction et pour toujours, de toute responsabilité en cas de réclamations, actions, dommages, procès, engagements, obligations, frais, honoraires et autres dépenses, y compris des honoraires raisonnables d’avocat, d’un tiers à l’encontre de l’un des Indemnisés en rapport avec une fausse déclaration, une négligence ou une faute de l’agent d’entiercement, de ses directeurs, membres de la direction, agents, employés et sous-traitants.

SPÉCIFICATION 3

FORMAT ET CONTENU DES RAPPORTS MENSUELS DE L’OPÉRATEUR DE REGISTRE

L’opérateur de registre doit fournir une série de rapports mensuels par gTLD, en utilisant l’API décrite dans draft-lozano-icann-registry-interfaces, voir spécification 2, partie A, article 9, référence 5, avec le contenu suivant.

À l’avenir, l’ICANN pourra exiger que les rapports soient remis via d’autres moyens et dans d’autres formats. L’ICANN s’engage à déployer des efforts commercialement raisonnables pour préserver la confidentialité des informations contenues dans les rapports jusqu’à trois (3) mois après la fin du mois sur lequel porte le rapport. Sauf tel que prévu dans la

présente spécification 3, toute référence à un moment précis se réfère à l’heure UTC (temps

universel coordonné). Les rapports mensuels doivent être constitués de données qui

reflètent l’état du registre à la fin du mois (UTC).

1. Rapport sur les transactions par bureau d’enregistrement. Ce rapport devra être établi au format CSV (valeurs séparées par des virgules), comme l’indique la norme RFC 4180. Le nom du fichier devra suivre le modèle « gTLD-transactions- aaaamm.csv » où « gTLD » est remplacé par le nom du gTLD ; s’il s’agit d’un IDN TLD, l’étiquette A doit être utilisée ; « aaaamm » doit être remplacé par l’année et le mois faisant l’objet du rapport. Le fichier doit contenir les champs suivants pour chaque bureau d’enregistrement :

Nº du cham p	Nom du champ	Description
01	registrar-name	Nom de société complet du bureau d’enregistrement tel qu’enregistré auprès de l’IANA
02	iana-id	Pour les cas où l’opérateur de registre agit à titre de bureau d’enregistrement (c’est-à-dire, sans l’utilisation d’un bureau d’enregistrement accrédité par l’ICANN), soit 9998, soit 9999 doit être utilisé en fonction du type d’enregistrement (comme décrit dans la spécification 5) ; sinon, l’ID IANA du bureau d’enregistrement parrain doit être utilisé tel qu’indiqué dans xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxxxxxxxx-xxx
03	total-domains	Nombre total de noms de domaine sous parrainage dans un statut EPP quelconque mais en pendingCreate qui n’ont pas été purgés.
04	total-nameservers	Nombre total de serveurs de noms (objets d’hôtes ou hôtes de serveurs de noms comme attributs de nom de domaine) associés à des noms de domaine

		enregistrés pour le TLD dans un statut EPP quelconque mais en pendingCreate qui n’ont pas été purgés.
05	net-adds-1-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale d’un (1) an (et non supprimés dans le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
06	net-adds-2-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de deux (2) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
07	net-adds-3-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de trois (3) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
08	net-adds-4-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de quatre (4) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
09	net-adds-5-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de cinq (5) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
10	net-adds-6-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de six (6) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être

		déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
11	net-adds-7-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de sept (7) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
12	net-adds-8-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de huit (8) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
13	net-adds-9-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de neuf (9) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
14	net-adds-10-yr	Nombre de domaines enregistrés avec succès (c’est-à-dire pas en statut EPP pendingCreate) pour une durée initiale de dix (10) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel le délai de grâce supplémentaire s’achève.
15	net-renews-1-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement d’un (1) an (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
16	net-renews-2-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de deux (2) ans (et non supprimés pendant le délai de grâce

		supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
17	net-renews-3-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de trois (3) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
18	net-renews-4-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de quatre (4) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
19	net-renews-5-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de cinq (5) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
20	net-renews-6-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de six (6) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
21	net-renews-7-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de sept (7)

		ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
22	net-renews-8-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de huit (8) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
23	net-renews-9-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de neuf (9) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
24	net-renews-10-yr	Nombre de domaines renouvelés avec succès (c’est-à-dire pas en statut EPP pendingRenew) automatiquement ou par commande pour une nouvelle période de renouvellement de dix (10) ans (et non supprimés pendant le délai de grâce supplémentaire). Une transaction doit être déclarée le mois au cours duquel la période de renouvellement ou d'autorenouvellement s'achève.
25	transfer-gaining-successful	Nombre de transferts de domaines initiés par ce bureau d’enregistrement qui ont été achevés avec succès (approuvés soit explicitement, soit automatiquement) et qui n’ont pas été supprimés au cours du délai de grâce de transfert. Une transaction doit être déclarée le mois au cours duquel le délai de grâce de transfert s’achève.
26	transfer-gaining-nacked	Nombre de transferts de domaines initiés par ce bureau d’enregistrement qui ont été rejetés (par exemple, transfert EPP op = « rejeter ») par l’autre bureau d’enregistrement.

27	transfer-losing-successful	Nombre de transferts de domaines initiés par un autre bureau d’enregistrement qui ont été achevés avec succès (approuvés soit explicitement, soit automatiquement).
28	transfer-losing-nacked	Nombre de transferts de domaines initiés par un autre bureau d’enregistrement que ce bureau d’enregistrement a rejetés (par exemple, transfert EPP op = « rejeter »).
29	transfer-disputed-won	Nombre de litiges de transfert pour lesquels ce bureau d’enregistrement a obtenu gain de cause (déclarés le mois où la détermination a eu lieu).
30	transfer-disputed-lost	Nombre de litiges de transfert que ce bureau d’enregistrement a perdu (déclarés le mois où la détermination a eu lieu).
31	transfer-disputed-nodecision	Nombre de litiges de transfert impliquant ce bureau d’enregistrement avec une scission ou une absence de décision (déclarés le mois où la détermination a eu lieu).
32	deleted-domains-grace	Domaines supprimés dans le délai de grâce supplémentaire (ne comprend pas les noms supprimés pendant la période en statut pendingCreate EPP). Une suppression doit être déclarée le mois au cours duquel le nom est purgé.
33	deleted-domains-nograce	Domaines supprimés en dehors du délai de grâce supplémentaire (ne comprend pas les noms supprimés pendant la période en statut pendingCreate EPP). Une suppression doit être déclarée le mois au cours duquel le nom est purgé.
34	restored-domains	Noms de domaine restaurés lors de la période de rapport.
35	restored-noreport	Nombre total des noms restaurés pour lesquels un rapport de restauration est requis par le registre, mais que le bureau d’enregistrement n’a pas envoyé.
36	agp-exemption-requests	Nombre total de demandes d’exemption du délai de grâce supplémentaire (AGP).
37	agp-exemptions-granted	Nombre total de demandes d’exemption du délai de grâce supplémentaire (AGP) accordées.
38	agp-exempted-domains	Nombre total de noms affectés par les demandes d’exemption du délai de grâce supplémentaire (AGP) accordées.

39 attempted-adds Nombre de commandes de création de nom de domaine tentées (réussites et échecs).

La première ligne doit comporter les noms de champs exactement comme décrit dans le tableau ci-dessus, en tant que « ligne d’en-tête », tel que décrit dans l’article 2 de la norme RFC 4180. La dernière ligne de chaque rapport doit inclure les totaux de chaque colonne de tous les bureaux d’enregistrement, dans le premier champ de cette ligne doit figurer

« Totaux », tandis que le second champ doit être laissé vide au niveau de cette ligne. Aucune autre ligne ne doit figurer dans le rapport. Les sauts de ligne seront réalisés avec <U+000D, U+000A> comme décrit dans la norme RFC 4180.

2. Rapport d’activité des fonctions de registre. Ce rapport devra être établi au format CSV (valeurs séparées par des virgules), comme l’indique la norme RFC 4180. Le nom du fichier devra suivre le modèle « gTLD-activity-aaaamm.csv » où

« gTLD » est remplacé par le nom du gTLD ; s’il s’agit d’un IDN TLD, l’étiquette A doit être utilisée ; « aaaamm » doit être remplacé par l’année et le mois faisant l’objet du rapport. Le fichier doit contenir les champs suivants :

Nº du champ	Nom du champ	Description
01	operational-registrars	Nombre de bureaux d’enregistrement opérationnels dans le système de production à la fin de la période de rapport.
02	zfa-passwords	Nombre de mots de passe d’accès au fichier de zone actifs à la fin de la période de rapport ; « CZDS » peut être utilisé au lieu du nombre de mots de passe d’accès au fichier de zone actifs si le service centralisé de données de zone (CZDS) est utilisé pour fournir le fichier de zone à l’utilisateur final.
03	whois-43-queries	Nombre de requêtes WHOIS (port 43) ayant reçu une réponse au cours de la période de rapport ; une valeur vide sera utilisée après la date de dissolution des services WHOIS (tel que défini dans la spécification 4) si le service WHOIS (port 43) n’est pas fourni après cette date.
04	web-whois-queries	Nombre de requêtes WHOIS basé sur le web ayant reçu une réponse au cours de la période de rapport, WHOIS consultable non compris ; une valeur vide sera utilisée après la date de dissolution des services WHOIS si le service WHOIS basé sur le web n’est pas fourni après cette date.

Nº du champ	Nom du champ	Description
05	searchable-whois-queries	Nombre de requêtes WHOIS consultable ayant reçu une réponse au cours de la période de rapport ; une valeur vide sera utilisée si le service WHOIS consultable n’est pas fourni au cours de la période de rapport.
06	dns-udp-queries-received	Nombre de requêtes DNS reçues par transport UDP au cours de la période de rapport.
07	dns-udp-queries-responded	Nombre de requêtes DNS reçues par transport UDP qui ont reçu une réponse au cours de la période de rapport.
08	dns-tcp-queries-received	Nombre de requêtes DNS reçues par transport TCP au cours de la période de rapport.
09	dns-tcp-queries-responded	Nombre de requêtes DNS reçues par transport TCP qui ont reçu une réponse au cours de la période de rapport.
10	srs-dom-check	Nombre de demandes de « contrôle » de nom de domaine SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
11	srs-dom-create	Nombre de demandes de « création » de nom de domaine SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
12	srs-dom-delete	Nombre de demandes de « suppression » de nom de domaine SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
13	srs-dom-info	Nombre de demandes « d’infos » de nom de domaine SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
14	srs-dom-renew	Nombre de demandes de « renouvellement » de nom de domaine SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
15	srs-dom-rgp-restore-report	Nombre de demandes de « restauration » RGP de nom de domaine SRS (EPP et toute autre interface) publiant un rapport de restauration ayant reçu une réponse au cours de la période de rapport.

Nº du champ	Nom du champ	Description
16	srs-dom-rgp-restore-request	Nombre de demandes de « restauration » RGP de nom de domaine SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
17	srs-dom-transfer-approve	Nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) visant à approuver des transferts ayant reçu une réponse au cours de la période de rapport.
18	srs-dom-transfer-cancel	Nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) visant à annuler des transferts ayant reçu une réponse au cours de la période de rapport.
19	srs-dom-transfer-query	Nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) visant à faire une demande concernant un transfert ayant reçu une réponse au cours de la période de rapport.
20	srs-dom-transfer-reject	Nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) visant à rejeter des transferts ayant reçu une réponse au cours de la période de rapport.
21	srs-dom-transfer-request	Nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) visant à demander des transferts ayant reçu une réponse au cours de la période de rapport.
22	srs-dom-update	Nombre de demandes de « mise à jour » de nom de domaine SRS (EPP et toute autre interface) (hors demandes de restauration) ayant reçu une réponse au cours de la période de rapport.
23	srs-host-check	Nombre de demandes de « contrôle » d’hôte SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
24	srs-host-create	Nombre de demandes de « création » d’hôte SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
25	srs-host-delete	Nombre de demandes de « suppression » d’hôte SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.

Nº du champ	Nom du champ	Description
26	srs-host-info	Nombre de demandes « d’infos » d’hôte SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
27	srs-host-update	Nombre de demandes de « mise à jour » d’hôte SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
28	srs-cont-check	Nombre de demandes de « contrôle » d’hôte SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
29	srs-cont-create	Nombre de demandes de « création » de contact SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
30	srs-cont-delete	Nombre de demandes de « suppression » de contact SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
31	srs-cont-info	Nombre de demandes « d’infos » de contact SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
32	srs-cont-transfer-approve	Nombre de demandes de « transfert » de contact SRS (EPP et toute autre interface) visant à approuver des transferts ayant reçu une réponse au cours de la période de rapport.
33	srs-cont-transfer-cancel	Nombre de demandes de « transfert » de contact SRS (EPP et toute autre interface) visant à annuler des transferts ayant reçu une réponse au cours de la période de rapport.
34	srs-cont-transfer-query	Nombre de demandes de « transfert » de contact SRS (EPP et toute autre interface) visant à faire une demande concernant un transfert ayant reçu une réponse au cours de la période de rapport.
35	srs-cont-transfer-reject	Nombre de demandes de « transfert » de contact SRS (EPP et toute autre interface) visant à rejeter des transferts ayant reçu une réponse au cours de la période de rapport.
36	srs-cont-transfer-request	Nombre de demandes de « transfert » de contact SRS (EPP et toute autre interface) visant à demander des transferts ayant reçu une réponse au cours de la période de rapport.

Nº du champ	Nom du champ	Description
37	srs-cont-update	Nombre de demandes de « mise à jour » de contact SRS (EPP et toute autre interface) ayant reçu une réponse au cours de la période de rapport.
38	requêtes-rdap	Nombre de requêtes RDAP ayant reçu une réponse au cours de la période de rapport.

La première ligne doit comporter les noms de champs exactement comme décrit dans le tableau ci-dessus, en tant que « ligne d’en-tête », tel que décrit dans l’article 2 de la norme RFC 4180. Aucune autre ligne ne doit figurer dans le rapport. Les sauts de ligne seront réalisés avec <U+000D, U+000A> comme décrit dans la norme RFC 4180.

Pour les gTLD qui font partie d'un système de registre partagé à instance unique : (1) les champs requêtes-whois-43, requêtes-whois-web, requêtes-whois-consultable et requêtes-rdap du rapport d’activité des fonctions de registre doivent correspondre à la somme des requêtes communiquées pour les gTLD dans le système de registre partagé à instance unique, (2) en cas de requêtes liés aux champs du point (1) susmentionné pour lesquels l’opérateur de registre ne peut déterminer à quel TLD est liée la requête (par exemple, une requête de consultation de bureau d’enregistrement pour un bureau d’enregistrement exploitant plus d’un TLD partageant la même URL de base du RDAP), les registres peuvent choisir le mode d’attribution de ces requêtes parmi les gTLD à l’aide du système de registre partagé à instance unique, et (3) le rapport d’activité des fonctions de registre peut inclure le nombre total de transactions de contact ou d’hôte pour tous les gTLD dans le système.

SPÉCIFICATION 4

SERVICES DE PUBLICATION DE DONNÉES D’ENREGISTREMENT

1. Services d'annuaire de données d'enregistrement

1.1. Définitions.

1.1.1 « Protocole d'accès aux données d'enregistrement des noms de domaine » ou « RDAP » désigne un protocole Internet qui fournit des services web « RESTful » visant à extraire les métadonnées

d’enregistrement des registres de noms de domaine et des registres

Internet régionaux.

1.1.2 « Services d’annuaire de RDAP » désigne un service d’annuaire de données d’enregistrement utilisant le RDAP décrit dans la norme STD 95 (xxxxx://xxx.xxx-xxxxxx.xxx/xxxx/xxx-xxx00.xxx) et ses normes subséquentes.

1.1.3 « Service d'annuaire de données d'enregistrement » ou « RDDS » désigne à la fois les services d'annuaire de données d'enregistrement WHOIS (tels que définis dans la présente spécification 4) et les services d'annuaire du protocole d'accès aux données d'enregistrement des noms de domaine (RDAP) (tels que définis dans la présente spécification 4).

1.1.4 « Service d'annuaire de données WHOIS » désigne à la fois le service WHOIS disponible via le port 43 conformément à la norme RFC 3912 et un service WHOIS basé sur le web offrant au public un accès gratuit par requêtes aux données d’enregistrement.

1.1.5 « Période de lancement du RDAP » désigne la période qui prendra fin le 3 février 2024.

1.1.6 « Date de dissolution des services WHOIS » désigne la date

correspondant à la fin d’une période de 360 jours après l’expiration de la période de lancement du RDAP, à condition que l’ICANN et le Groupe des représentants des opérateurs de registres puissent se mettre d’accord sur le report de la date de dissolution des services WHOIS. Si soit le président-directeur général (le « PDG ») de l'ICANN soit le président du Groupe des représentants des opérateurs de registres (le « Président ») souhaite discuter du report de la date de dissolution des services WHOIS, le PDG ou le Président, selon le cas, en informera l’autre par écrit en exposant de façon suffisamment détaillée la proposition de report.

1.2. RDAP/Services d’annuaire

1.2.1 L’opérateur de registre mettra en œuvre la dernière version du guide de mise en œuvre technique du RDAP et du profil de réponse RDAP publiée sur xxxxx://xxxxx.xxx/xxxx-xxxx-xxxxxxx. L’opérateur de

registre mettra en œuvre de nouvelles versions du guide de mise en œuvre technique du RDAP et du profil de réponse RDAP dans un délai maximum de cent quatre-vingts (180) jours civils à compter de la notification de l’ICANN.

1.2.2 L’opérateur de registre fournira un soutien aux requêtes de

consultation pour :

(1) les informations du domaine telles que décrites dans la section

« Spécification relative au segment d’accès xx xxxxxxx » xx xx xxxxx XXX 0000.

(2) les informations du serveur de noms telles que décrites dans la section « Spécification relative au segment d’accès au serveur de noms » de la norme RFC 9082, à condition, toutefois, que l’opérateur de registre ne soit pas tenu (mais puisse tout de même décider s’il le souhaite) d’apporter un soutien à la consultation de serveurs de noms si l’opérateur de registre indique que des serveurs de noms constituent des attributs du domaine dans l’EPP.

(3) les informations du bureau d’enregistrement telles que décrites dans la section « Spécification relative au segment d’accès à l’entité » de la norme RFC 9082.

(4) des informations de soutien telles que décrites dans la section

« Spécification relative au segment d’accès xx xxxxxxx » xx xx xxxxx XXX 0000.

1.2.3 L’ICANN se réserve le droit de définir des formats et protocoles alternatifs qualifiés de « Normes Internet » (par opposition aux

normes informatives ou expérimentales) via les processus de l’IETF applicables concernant les données d’enregistrement. Pour une telle définition, l’ICANN : (a) travaillera en collaboration avec les registres gTLD et les bureaux d’enregistrement accrédités par l’ICANN afin de poser toutes les exigences opérationnelles requises pour la mise en œuvre de la norme applicable ; et (b) le cas échéant, engagera des négociations visant à poser toutes les exigences de déclaration (s’il y en a) et des exigences raisonnables en matière de convention de service dans la lignée des exigences correspondant à des services de même niveau.

1.3. Facilité de recherche. Des fonctions de recherche peuvent être proposées, en option, pour les données d’enregistrement. Mais si elles sont proposées par l’opérateur de registre, elles doivent respecter la spécification décrite dans le présent article.

1.3.1 L’opérateur de registre proposera une facilité de recherche en tant que service basé sur le web.

1.3.2 L’opérateur de registre proposera des fonctions de correspondance partielle dans chacun des champs suivants : nom de domaine, contacts et nom du titulaire de nom de domaine, et contact et adresse postale du titulaire de nom de domaine, y compris tous les sous-champs

décrits dans l’EPP (par ex., rue, ville, État ou province, etc.). Il pourra

aussi proposer des fonctions de correspondance partielle dans

d’autres champs, dans tous les cas dans le respect du droit applicable.

1.3.3 L’opérateur de registre proposera des fonctions de correspondance exacte au minimum dans les champs suivants : ID du bureau d'enregistrement, nom du serveur de noms et adresse IP du serveur de noms (s’applique uniquement aux adresses IP stockées par le

registre, c’est-à-dire aux enregistrements de type glue).

1.3.4 L’opérateur de registre proposera des fonctions de recherche booléenne prenant en charge, au minimum, les opérateurs logiques suivants pour regrouper un ensemble de critères de recherche : ET, OU, SAUF (AND, OR, NOT).

1.3.5 Les résultats de recherche incluront les noms de domaine correspondant aux critères de recherche.

1.3.6 L’opérateur de registre : 1) mettra en œuvre des mesures appropriées permettant d’éviter tout abus de cette fonctionnalité (par ex., en accordant un accès uniquement aux utilisateurs autorisés légitimes) ; et 2) s’assurera que la fonctionnalité est conforme à toutes les lois en vigueur en matière de vie privée et aux politiques de consensus et politiques temporaires de l’ICANN.

1.3.7 L’opérateur de registre proposera uniquement les fonctions de

recherche requises dans le guide de mise en œuvre technique du RDAP et le profil de réponse RDAP dans les services d’annuaire du RDAP.

1.4. Services d’annuaire de données WHOIS

1.4.1 Jusqu'à la date de dissolution des services WHOIS, l'opérateur de registre assurera un service WHOIS disponible via le port 43 conformément à la norme RFC 3912 et un service WHOIS basé sur le

web à l'adresse <whois.nic.TLD>, fournissant un accès public gratuit par requêtes au moins aux éléments suivants, sous le format suivant.

1.4.2 Le format des réponses doit respecter un format de texte semi-libre présenté ci-dessous, suivi d’une ligne vide et d’une clause de non-

responsabilité légale spécifiant les droits de l’opérateur de registre et

ceux de l’utilisateur interrogeant la base de données.

1.4.3 Chaque élément de données sera représenté sous forme d’un ensemble de paires clé/valeur ; les lignes doivent commencer par la clé, suivie de deux-points, d’un espace et de la valeur.

1.4.4 Si un champ comporte plusieurs valeurs, il est possible de présenter plusieurs paires clé/valeur comportant la même clé (par exemple pour répertorier plusieurs serveurs de noms). La première paire clé/valeur située après une ligne vide doit être considérée comme le début d’un nouvel enregistrement, elle doit identifier cet enregistrement et être utilisée pour regrouper des données, telles que des noms d’hôtes et des adresses IP, ou un nom de domaine et des informations sur le titulaire du nom de domaine.

1.4.5 Les champs spécifiés ci-dessous énoncent les exigences minimales de résultats.

1.4.6 Données des noms de domaine :

(1) Format de la requête : whois EXEMPLE.TLD

(2) Format de la réponse :

Nom de domaine : EXEMPLE.TLD

ID du domaine de registre : D1234567-TLD

Serveur WHOIS du bureau d’enregistrement : whois.exemple.tld URL du bureau d’enregistrement : xxxx://xxx.xxxxxxx.xxx Date de mise à jour : 2009-05-29T20:13:00Z

Date de création : 2000-10-08T00:45:00Z

Date d'expiration du registre : 2010-10-08T00:44:59Z

Date d'expiration de l'enregistrement du bureau d’enregistrement : 2010-10- 08T00:44:59Z1

Bureau d’enregistrement : EXEMPLE BUREAU D'ENREGISTREMENT LLC

ID IANA du bureau d’enregistrement : 5555555

Courriel du point de contact du bureau d'enregistrement prévu pour signaler des cas d'abus : xxxxx@xxxxxxxxx.xxx

Numéro de téléphone du point de contact du bureau d'enregistrement prévu pour signaler des cas d'abus : +1.123551234

Revendeur : EXEMPLE REVENDEUR12

Statut du domaine : clientSuppressionInterdit

1 Ce champ est facultatif.

2 Ce champ est facultatif.

Statut du domaine : clientRenouvellementInterdit Statut du domaine : clientTransfertInterdit

Statut du domaine : serveurMiseàjourInterdit

ID du titulaire de nom de domaine du registre : 5372808-ERL

Nom du titulaire du nom de domaine : EXEMPLE TITULAIRE DU NOM DE DOMAINE Organisation du titulaire du nom de domaine : EXEMPLE ORGANISATION

Rue du titulaire du nom de domaine : 123 EXEMPLE RUE Ville du titulaire du nom de domaine : VILLE QUELCONQUE État/province du titulaire du nom de domaine : AP

Code postal du titulaire du nom de domaine : A1A1A1 Pays du titulaire du nom de domaine : EX

Numéro de téléphone du titulaire du nom de domaine : +1.5555551212 Numéro de poste du titulaire du nom de domaine : 1234

Numéro de télécopie du titulaire du nom de domaine : +1.5555551213 Numéro de poste de télécopie du titulaire du nom de domaine : 4321

Courrier électronique du titulaire du nom de domaine : XXXXX@XXXXXXX.XXX

ID de l’administrateur du registre : 5372809-ERL

Nom de l’administrateur : EXEMPLE ADMINISTRATEUR DU TITULAIRE DU NOM DE DOMAINE

Organisation de l’administrateur : EXEMPLE ORGANISATION DU TITULAIRE DU NOM DE DOMAINE

Rue de l'administrateur : 000 XXXXXXX XXX Xxxxx de l'administrateur : VILLE QUELCONQUE État/province de l’administrateur : AP

Code postal de l'administrateur : A1A1A1 Pays de l'administrateur : EX

Numéro de téléphone de l'administrateur : +1.5555551212 Numéro de poste de l'administrateur : 1234

Numéro de télécopie de l'administrateur : +1.5555551213

Numéro de poste de télécopie de l’administrateur :

Adresse électronique de l’administrateur : XXXXX@XXXXXXX.XXX ID du technicien du registre : 5372811-ERL

Nom du technicien : EXEMPLE TECHNICIEN DU BUREAU D’ENREGISTREMENT

Organisation du technicien : EXEMPLE BUREAU D’ENREGISTREMENT LLC

Rue du technicien : 000 XXXXXXX XXX Xxxxx du technicien : VILLE QUELCONQUE État/province du technicien : AP

Code postal du technicien : A1A1A1 Pays du technicien : EX

Numéro de téléphone du technicien : +1.1235551234 Numéro de poste du technicien : 1234

Numéro de télécopie du technicien : +1.5555551213 Numéro de poste de télécopie du technicien : 93

Adresse électronique du technicien : XXXXX@XXXXXXX.XXX

Serveur de noms : NS01.EXEMPLEBUREAUD’ENREGISTREMENT.TLD

Serveur de noms : NS02.EXEMPLEBUREAUD’ENREGISTREMENT.TLD

DNSSEC : Délégationsignée DNSSEC : non signée

URL du formulaire de plainte pour inexactitude des données WHOIS de l’ICANN : xxxxx://xxx.xxxxx.xxx/xxxx/

>>> Dernière mise à jour de la base de données WHOIS : 2009-05-29T20:15:00Z

<<<

1.4.7 Données relatives au bureau d’enregistrement

(1) Format de la requête : « bureau d'enregistrement Exemple

Bureau d’enregistrement, Inc. » du whois

(2) Format de la réponse :

Bureau d’enregistrement : Exemple Bureau d'enregistrement, Inc. Rue : 0000 Xxxxxxxxx Xxx

Ville : Marina del Rey
État/Province : CA Code postal : 90292

Pays : États-Unis

Numéro de téléphone : +1.3105551212 Numéro de télécopie : +1.3105551213

E-mail : xxxxxxxxxxxxxxxxxxxxx@xxxxxxx.xxx

Serveur WHOIS du bureau d'enregistrement : whois.exemple- bureaudenregistrement.tld

URL du bureau d’enregistrement : xxxx://xxx.xxxxxxx-xxxxxxxxxxxxxxxxxxxxx.xxx Contact de l'administrateur : Xxx Xxxxxx d’enregistrement

Numéro de téléphone : +1.3105551213 Numéro de télécopie : +1.3105551213

E-mail : xxxxxxxxxxxxxxxxxxxxxxxx@xxxxxxx-xxxxxxxxxxxxxxxxxxxxx.xxx Contact de l'administrateur : Xxxx Xxxxxx d’enregistrement

Numéro de téléphone : +1.3105551214 Numéro de télécopie : +1.3105551213

E-mail : xxxxxxxxxxxxxxxxxxxxxxxxx@xxxxxxx-xxxxxxxxxxxxxxxxxxxxx.xxx Contact du technicien : Xxxx Xxxx

Numéro de téléphone : +1.3105551215 Numéro de télécopie : +1.3105551216

E-mail : xxxxxxxx@xxxxxxx-xxxxxxxxxxxxxxxxxxxxx.xxx

>>> Dernière mise à jour de la base de données WHOIS : 2009-05-29T20:15:00Z

<<<

1.4.8 Données relatives au serveur de nom :

(1) Format de la requête : « serveur de noms (nom de serveur de noms) » du whois, ou « serveur de noms (adresse IP) » du whois. Par exemple : « serveur de noms NS1.EXEMPLE.TLD » du whois.

(2) Format de la réponse :

Nom de serveur : NS1.EXEMPLE.TLD Adresse IP : 192.0.2.123

Adresse IP : 2001:0DB8::1

Bureau d’enregistrement : Exemple Bureau d’enregistrement, Inc. Serveur WHOIS du bureau d’enregistrement : whois.exemple- bureaudenregistrement.tld

URL du bureau d’enregistrement : xxxx://xxx.xxxxxxx-xxxxxxxxxxxxxxxxxxxxx.xxx

>>> Dernière mise à jour de la base de données WHOIS : 2009-05-29T20:15:00Z

<<<

1.4.9 Le format des champs de données suivants : statut de domaine, noms de personnes et d’organisations, adresse, rue, ville, État/province, code postal, pays, numéros de téléphone et de fax (l’extension sera fournie dans un champs séparé comme montré ci-dessus), adresses électroniques, dates et heures doivent correspondre aux mappages spécifiés par les normes EPP RFC 5730 à 5734, afin que l’affichage de ces informations (ou des valeurs renvoyées dans les réponses WHOIS) puisse être traité et compris de façon uniforme.

1.5. Services d’annuaire de données Whois après la date de dissolution des services WHOIS. Si l’Opérateur de registre continue à proposer des Services d’annuaire de données Whois après la Date de dissolution des services

WHOIS, les conditions suivantes s’appliqueront :

1.5.1 Si l’opérateur de registre continue à proposer un service WHOIS disponible via le port 43, l’opérateur de registre devra respecter la norme RFC 3912.

1.5.2 L’opérateur de registre soumettra une demande de modification à l’opérateur des fonctions IANA visant à mettre à jour les enregistrements WHOIS du TLD obsolètes ou inexacts tel que décrit à l’article 1.6 de la spécification 6.

1.5.3 Les données personnelles comprises dans les données

d’enregistrement doivent être expurgées conformément aux

politiques de consensus et aux politiques temporaires de l’ICANN.

1.5.4 L’opérateur de registre doit respecter les conditions relatives aux champs supplémentaires de la politique sur l'étiquetage et l'affichage normalisés s’il décide d’ajouter des champs de données.

1.5.5 Si l’opérateur de registre fournit moins de données d’enregistrement dans les services d’annuaire de données WHOIS que celles disponibles dans les services d’annuaire du RDAP, l’opérateur de registre doit ajouter la clause de non-responsabilité suivante en bas de page des résultats du WHOIS : « Les données d’enregistrement disponibles dans le cadre de ce service sont limitées. Des données

supplémentaires sont disponibles à l’adresse suivante : xxxxx://xxxxxx.xxxxx.xxx. »

1.5.6 Après la date de dissolution des services WHOIS, en cas de conflit entre les exigences du service d'annuaire de données WHOIS et celles des politiques de consensus ou politiques temporaires entrant en vigueur après la date de dissolution des services WHOIS, les politiques de consensus et politiques temporaires prévaudront, mais uniquement en ce qui concerne l’objet du conflit.

1.5.7 Jusqu’à l’entrée en vigueur des mises à jour des politiques de consensus et des procédures conformément aux recommandations de politiques de consensus de la GNSO issues de l’étape 1 du processus accéléré d'élaboration de politiques sur la spécification temporaire

relative aux données d’enregistrement des gTLD, adoptées par le

Conseil d’administration de l’ICANN en mai 2019, à compter de la date de dissolution des services WHOIS, les termes suivants desdites politiques seront interprétés tel que suit :

(1) À l’exception du « Whois consultable » et du « service de consultation des contacts Whois », les termes suivants :

« WHOIS », « Whois », « service Whois », « Whois accessible au public » et leurs variantes seront entendus comme faisant référence au RDDS, tel que défini dans la présente Spécification.

(2) « données Whois », « informations Whois », « coordonnées Whois », « données des requêtes Whois », « détails Whois »,

« résultats Whois », « enregistrement Whois », « entrée Whois » et leurs variantes seront entendus comme faisant

référence aux données d’enregistrement, tel que mentionné

dans la présente spécification.

1.6. Après la Date de dissolution des services WHOIS, les termes des dispositions 1.5.7(1) et 1.5.7(2) ci-dessus, compris dans l’Annexe A et les Spécifications 11 et 12, seront interprétés tel que défini dans les dispositions 1.5.7(1) et 1.5.7(2).

1.7. Coopération dans le cadre d’études sur la transition. Si l’ICANN lance ou commande une étude sur la transition des Services d’annuaire de données WHOIS vers les Services d’annuaire du RDAP, l’Opérateur de registre participera, dans la mesure du raisonnable, à une telle étude, notamment en fournissant à l’ICANN ou à son représentant menant l’étude des données quantitatives et qualitatives liées à son expérience concernant cette

transition des Services d’annuaire de données WHOIS vers les Services d’annuaire de données du RDAP. Si la demande de données dépasse ce que l’Opérateur de registre collecte dans le cadre normal de ces opérations et dépasse les données que l’Opérateur de registre est tenu de collecter et de fournir à l’organisation ICANN conformément au présent Contrat, l’Opérateur de registre doit coopérer à titre volontaire en fournissant les informations

requises ou en expliquant à l’ICANN pourquoi l’Opérateur de registre n’est

pas en mesure de fournir les informations requises. Les dispositions du

présent article n’imposent pas à l’Opérateur de registre de fournir à l’ICANN des données qui vont au-delà de ce que l’Opérateur de registre est tenu de fournir à l’ICANN conformément à d’autres articles du présent Contrat.

Toutes les données remises à l'ICANN ou à son représentant conformément au présent article qui sont dûment qualifiées de confidentielles conformément aux dispositions relatives à la confidentialité du Contrat seront traitées comme des Informations confidentielles de l'Opérateur de registre en vertu des dispositions relatives à la confidentialité du Contrat, à condition que, nonobstant le Contrat, si l'ICANN ou son représentant regroupe et anonymise lesdites données, l'ICANN ou son représentant puisse divulguer lesdites données à des tiers. À la conclusion de l’étude sur la transition pour laquelle l'Opérateur de registre a fourni des données, l'ICANN détruira toutes les données fournies par l'Opérateur de registre

conformément au présent article qui n'auront pas été regroupées et anonymisées.

1.8. Supports politiques et éducatifs L’opérateur de registre doit fournir un lien

sur le principal site web dédié au TLD (c’est-à-dire, le site web fourni à l’ICANN à des fins de publication sur le site web de l’ICANN) vers une page web désignée par l’ICANN contenant la politique RDDS et les supports éducatifs.

2. Accès au fichier de zone

2.1. Accès des tiers

2.1.1 Contrat d'accès au fichier de zone. L’opérateur de registre s’engage à conclure avec tout internaute un contrat autorisant ledit internaute à accéder à un ou plusieurs serveurs hôtes, désignés par l’opérateur de registre, et à télécharger des données de fichier de zone. Le contrat sera normalisé, fourni et administré par un Fournisseur d’accès aux données de la zone centralisée qui peut être l’ICANN ou son représentant (le « Fournisseur de CZDA »). L’Opérateur de registre (éventuellement via le Fournisseur de CZDA) fournira l’accès aux données de fichier de zone conformément à l’article 2.1.3 de la présente Spécification, et ce en utilisant le format de fichier décrit dans l’article 2.1.4 de la présente Spécification. Nonobstant ce qui précède, (a) le Fournisseur de CZDA peut rejeter la demande d'accès de tout utilisateur qui ne satisfait pas aux exigences d'identification prévues à l'article 2.1.2 de la présente Spécification ; (b) l'Opérateur de registre peut rejeter la demande d'accès de tout utilisateur qui ne fournit pas d'informations d'identification correctes ou légitimes conformément à l'article 2.1.2 de la présente Spécification ou si l'Opérateur de registre estime, dans la mesure du raisonnable, qu'il enfreindra les dispositions de l'article 2.1.5. de la présente Spécification ; et (c) l'Opérateur de registre peut révoquer l'accès de tout utilisateur si l'Opérateur de registre est en mesure de prouver que l'utilisateur a enfreint les dispositions de l'article 2.1.5 de la présente Spécification.

2.1.2 Exigences d'identification. L’opérateur de registre, par

l’intermédiaire du fournisseur CZDA, exigera que chaque utilisateur lui fournisse des informations suffisantes pour bien identifier et localiser ledit utilisateur. Ces informations sur l’utilisateur incluront, sans s’y limiter, le nom de la société, le nom du contact, l’adresse, le numéro de téléphone, le numéro de télécopieur, l’adresse

électronique et l’adresse IP.

2.1.3 Octroi d'accès. Chaque opérateur de registre (de manière facultative par l’intermédiaire du fournisseur CZDA) fournira le service SFTP de fichier de zone (ou autre service pris en charge par le registre) pour une URL gérée et spécifiée par l’ICANN (spécifiquement,

<TLD>.xxx.xxxxx.xxx où <TLD> est le TLD dont le registre est

responsable) pour que l’utilisateur accède aux archives de données de zone du registre. L’opérateur de registre s’engage à accorder à l’utilisateur un droit limité non transférable et non exclusif d’accès au serveur hôte de fichier de zone de l’opérateur de registre (facultativement du fournisseur CZDA) et de transfert d’une copie des fichiers de zone de domaine de premier niveau ainsi que de tout fichier chiffré de contrôle associé pas plus d’une fois par période de 24 heures, via SFTP ou tout autre protocole d’accès et de transport de données éventuellement prescrit par l’ICANN. Pour chaque serveur d’accès au fichier de zone, les fichiers de zone se trouvent dans le répertoire de premier niveau appelé <zone>.zone.gz, avec

<zone>.gz.md5 et <zone>.zone.gz.sig pour vérifier les téléchargements. Si l’opérateur de registre (ou le fournisseur CZDA) fournit également des données d’historique, il utilisera le modèle d’attribution de nom <zone>-aaaammjj.zone.gz, etc.

2.1.4 Norme de format de fichiers. L’opérateur de registre (de manière facultative par l’intermédiaire du fournisseur CZDA) fournira des fichiers de zone en utilisant un sous-format du format standard fichier maître comme défini à l’origine dans la norme RFC 1035, article 5, y compris tous les enregistrements présents dans la zone actuellement utilisés dans le DNS public. Le sous-format est comme suit :

1. Chaque enregistrement doit présenter tous les champs sur une seule ligne, comme suit : <domain-name> <TTL> <class>

<type> <RDATA>.

2. La classe et le type doivent utiliser la norme mnémonique et être en minuscules.

3. Le TTL doit être présenté sous la forme d’un nombre décimal.

4. L’utilisation de \X et de \DDD dans les noms de domaine est autorisée.

5. Tous les noms de domaine doivent être en minuscules.

6. Dans un enregistrement, une seule tabulation doit être utilisée pour séparer les champs.

7. Tous les noms de domaine doivent être renseignés en entier.

8. Pas de directive $ORIGIN.

9. Pas d’utilisation du « @ » pour annoncer l’origine actuelle.

10. Pas d’utilisation du « nom de domaine en blanc » au début d’un enregistrement pour continuer à utiliser le nom de domaine dans l’enregistrement précédent.

11. Pas de directive $INCLUDE.

12. Pas de directive $TTL.

13. Pas d’utilisation de parenthèses, par exemple pour continuer la

liste des champs d’un enregistrement, après le bout de la ligne.

14. Pas de commentaires.

15. Pas de lignes blanches.

16. Un enregistrement SOA doit se trouver au début et (copié) à la fin du fichier de zone.

17. À l’exception de l’enregistrement SOA, tous les

enregistrements d’un fichier doivent être classés par ordre

alphabétique.

18. Une zone par fichier. Si un TLD divise ses données DNS en plusieurs zones, chaque zone va dans un fichier distinct renommé comme ci-dessus. Pour combiner tous les fichiers, utiliser tar dans un fichier appelé <tld>.zone.tar.

2.1.5 Utilisation des données par l’utilisateur. L’opérateur de registre permettra à l’utilisateur d’utiliser le fichier de zone à des fins licites, à condition que (a) l’utilisateur prenne toutes les mesures raisonnables pour protéger les données contre tout accès, utilisation et divulgation non autorisés, et (b) l’opérateur de registre ne soit en aucun cas tenu de ou autorisé à permettre à l’utilisateur d’utiliser les données pour

(i) permettre, autoriser ou soutenir les activités de marketing d’entités autres que les clients existants de l’utilisateur, indépendamment du moyen utilisé (ces moyens comprenant, sans s’y limiter, la transmission par e-mail, téléphone ou fax, courrier postal, SMS et alertes sans fil de publicités ou annonces commerciales massives non demandées à des entités), (ii) mettre en place des processus électroniques automatisés à grand volume qui envoient des requêtes ou des données aux systèmes de l’opérateur de registre ou d’un bureau d’enregistrement accrédité par l’ICANN, ou (iii)

interrompre, perturber ou interférer dans les opérations commerciales habituelles de tout titulaire de nom de domaine.

2.1.6 Période d'utilisation. L’opérateur de registre, par l’intermédiaire du fournisseur CZDA, s’engage à fournir à chaque utilisateur un accès au fichier de zone durant une période minimale de trois (3) mois.

L’opérateur de registre autorisera les utilisateurs à renouveler leur octroi d’accès.

2.1.7 Accès fourni sans paiement de droits. L’opérateur de registre s’engage à fournir à l’utilisateur un accès gratuit au fichier de zone et le fournisseur CZDA s’engage à faciliter cet accès.

2.2. Coopération

2.2.1 et aide. L’opérateur de registre s’engage à coopérer et à fournir une aide raisonnable à l’ICANN et au fournisseur CZDA pour faciliter et gérer l’accès efficace aux données du fichier de zone par les utilisateurs autorisés visés par ce programme.

2.3. Accès de l’ICANN. L’opérateur de registre s’engage à fournir un accès groupé aux fichiers de zones pour le TLD à l’ICANN ou à son représentant, de façon continue, tel que l’ICANN pourra occasionnellement le spécifier de manière

raisonnable. L’accès sera fourni au moins quotidiennement. Les fichiers de zone comprendront des données SRS enregistrées aussi près que possible de 00 h 00 UTC.

2.4. Accès de l’opérateur d’urgence. L’opérateur de registre s’engage à fournir un accès groupé aux fichiers de zones pour le TLD aux opérateurs d’urgence désignés par l’ICANN, de façon continue, tel que l’ICANN pourra occasionnellement le spécifier de manière raisonnable.

3. Accès groupé de l’ICANN aux données d’enregistrement

3.1. Accès périodique aux données d’enregistrement « résumées ». Afin de vérifier et de garantir la stabilité opérationnelle des Services de registre, d’analyser la stabilité opérationnelle du DNS et de faciliter les vérifications de conformité des bureaux d’enregistrement accrédités, l’Opérateur de registre fournira toutes les semaines à l’ICANN (jour à préciser par l’ICANN) des Données d’enregistrement à jour tel qu’indiqué ci-dessous. Ces données incluront des données enregistrées à 00 h 00 UTC le jour précédent le jour de récupération spécifié par l’ICANN.

Chaque année, l’ICANN publiera une synthèse des projets de recherche ayant utilisé ces données au cours de l’année précédente ainsi qu’une liste des organisations à qui les données brutes ont été partagées afin de mener les recherches.

3.1.1 Contenus. L’Opérateur de registre fournira les données suivantes pour tous les noms de domaines enregistrés : nom de domaine, identificateur de l’objet référencé du nom de domaine (roid), ID du bureau d’enregistrement (ID IANA), statuts, date de dernière mise à jour, date de création, date d’expiration et noms du serveur de noms. Pour les bureaux d'enregistrement parrains, l’opérateur de registre fournira les données suivantes : nom du bureau d’enregistrement, ID du bureau d’enregistrement (ID IANA), nom d’hôte du serveur WHOIS du bureau d’enregistrement (ces éléments de données pouvant être omis après la date de dissolution des services WHOIS), et l’URL du bureau d’enregistrement. L’Opérateur de registre ne fournira pas d’éléments de données supplémentaires.

3.1.2 Format. Les données seront fournies au format spécifié dans la spécification 2 pour l’entiercement de données (y compris le chiffrement, la signature, etc.) mais en incluant uniquement les champs mentionnés au paragraphe précédent. Autrement dit, le fichier contiendra uniquement les objets domaine et bureau d’enregistrement ainsi que les champs mentionnés ci-dessus.

L’opérateur de registre a la possibilité de fournir à la place un fichier de dépôt complet tel que spécifié dans la spécification 2.

3.1.3 Accès. L’opérateur de registre aura le ou les fichiers prêts à télécharger à partir de 00 h 00 UTC le jour de récupération spécifié par l’ICANN. Le ou les fichiers seront disponibles pour le

téléchargement par SFTP. À l’avenir, l’ICANN pourra toutefois exiger d’autres moyens de téléchargement.

3.2. Accès exceptionnel aux données d’enregistrement « détaillées ». En cas de défaillance du bureau d’enregistrement, d’annulation de l’accréditation, d’une décision de justice, etc. requérant le transfert temporaire ou définitif de ses noms de domaine vers un autre bureau d’enregistrement, à la demande de l’ICANN, l’opérateur de registre fournira à l’ICANN des données mises à jour des noms de domaine du bureau d’enregistrement sortant. Les données seront fournies au format spécifié à la spécification 2 pour

l’entiercement de données. Le fichier contiendra uniquement les données concernant les noms de domaine du bureau d’enregistrement sortant.

L’opérateur de registre fournira les données dès que possible d’un point de vue commercial, mais en tout cas au plus tard cinq (5) jours civils à compter de la demande de l’ICANN. À moins que l’opérateur de registre et l’ICANN n’en aient convenu autrement, le fichier sera disponible au téléchargement par l’ICANN de la même manière que les données spécifiées dans l’article 3.1. de la présente spécification.

SPÉCIFICATION 5 PROGRAMME DES NOMS RÉSERVÉS

Sauf en cas d’autorisation expresse écrite de l’ICANN, et conformément aux conditions

générales de la présente spécification, l’opérateur de registre devra réserver à

l’enregistrement initial (et non pas au renouvellement) les noms formés avec les étiquettes suivantes dans le TLD. S’il utilise l’autoattribution, l’opérateur de registre doit montrer l’enregistrement dans le RDDS. Dans le cas de noms IDN (comme indiqué ci-dessous), les variantes IDN seront identifiées en fonction de la politique d’enregistrement IDN de

l’opérateur de registre, le cas échéant.

1. Exemple. L’étiquette ASCII « EXEMPLE » sera exclue de l’enregistrement ou

attribuée à l’opérateur de registre au deuxième niveau et à tous les autres niveaux au sein du TLD dans lequel l’opérateur de registre offre des enregistrements (ce deuxième niveau et tous les autres niveaux sont collectivement désignés « Tous les niveaux »). Cette étiquette ne peut être activée dans le DNS et ne peut être mise à disposition à des fins d’enregistrement par des personnes ou entités autres que l’opérateur de registre. Une fois qu’un opérateur de registre est désigné pour exploiter un TLD, toutes les étiquettes exclues ou attribuées devront être

transférées, tel que spécifié par l’ICANN. L’opérateur de registre peut s’autoattribuer

et renouveler ce nom sans utiliser un bureau d’enregistrement accrédité par

l’ICANN, ce qui ne sera pas considéré comme une transaction aux fins de l’article 6.1

du contrat.

2. Étiquettes à deux caractères. Toutes les étiquettes ASCII à deux caractères seront exclues de l’enregistrement ou attribuées à l’opérateur de registre au deuxième niveau dans le TLD. Ces étiquettes ne peuvent être activées dans le DNS et ne peuvent être débloquées à des fins d’enregistrement par toute personne ou entité autre que l’opérateur de registre, à condition que ces chaînes d’étiquettes à deux caractères puissent être débloquées si l’opérateur de registre parvient à un accord avec le gouvernement concerné et avec le gestionnaire d’extension géographique de la chaîne comme indiqué dans la norme ISO 3166-1 alpha-2. L’opérateur de registre peut également proposer de débloquer ces réservations en fonction de la mise en œuvre de mesures visant à éviter la confusion avec les extensions géographiques correspondantes, sous réserve de l’approbation de l’ICANN. Une fois qu’un opérateur de registre est désigné pour exploiter un TLD, toutes ces étiquettes qui sont exclues de l’enregistrement ou attribuées à l’opérateur de registre doivent être

transférées, tel que spécifié par l’ICANN. L’opérateur de registre peut s’autoattribuer et renouveler ces noms sans utiliser un bureau d’enregistrement accrédité par

l’ICANN, ce qui ne sera pas considéré comme une transaction aux fins de l’article 6.1

du contrat.

3. Réservations pour les opérations de registre.

3.1. Les étiquettes ASCII suivantes doivent être exclues de l’enregistrement ou attribuées à l’opérateur de registre à tous les niveaux à des fins d’utilisation dans le cadre de l’exploitation du registre pour le TLD : WWW, RDDS et WHOIS. L’étiquette ASCII suivante doit être attribuée à l’opérateur de registre suite à la délégation dans la zone racine à tous les niveaux à des fins d’utilisation dans le cadre de l’exploitation du registre pour le TLD : NIC. L’opérateur de registre peut activer les étiquettes WWW, RDDS et WHOIS dans le DNS, mais doit activer l’étiquette NIC dans le DNS, si cela s’avère nécessaire pour l’exploitation du TLD (conformément aux dispositions de l’annexe A, l’étiquette ASCII NIC doit être fournie dans le DNS en tant que section de zone à l’aide des enregistrements de ressources NS). Aucune des étiquettes WWW, RDDS, WHOIS ou NIC ne peut être débloquée ou

enregistrée par une personne (autre qu’un opérateur de registre) ou un tiers. Une fois qu’un opérateur de registre est désigné pour exploiter un TLD, tous ces noms exclus ou attribués devront être transférés, tel que spécifié par

l’ICANN. L’opérateur de registre peut s’autoattribuer et renouveler ces noms sans utiliser un bureau d’enregistrement accrédité par l’ICANN, ce qui ne sera pas considéré comme une transaction aux fins de l’article 6.1 du contrat. Ces domaines devront être identifiés par l’ID de bureau d’enregistrement 9999.

3.1.1 Si l’annexe A du contrat prévoit spécifiquement que l’opérateur de

registre peut proposer l’enregistrement d’IDN, l’opérateur de registre pourra également activer la traduction linguistique spécifique ou la translittération du terme « NIC » ou une abréviation de la traduction du terme « Centre d’information de réseaux » dans le DNS

conformément aux tables d’IDN et aux règles d’enregistrement d’IDN de l’opérateur de registre. Une telle traduction, translittération ou abréviation pourront être réservées par l’opérateur de registre et

utilisées en plus de l’étiquette NIC pour fournir toutes les fonctions de registre nécessaires. Dans un souci de clarté, l’Opérateur de registre est tenu d’activer l’étiquette du NIC en ASCII conformément à l’article

3.1 de la présente Spécification 5.

3.2. L’opérateur de registre peut activer dans le DNS à tous les niveaux jusqu’à cent (100) noms (plus leurs variantes IDN, le cas échéant) nécessaires à l’exploitation ou la promotion du TLD. L’opérateur de registre doit agir comme titulaire du nom enregistré de ces noms, ce terme étant défini dans le contrat d’accréditation de bureau d’enregistrement (RAA) alors en vigueur de l’ICANN. Ces activations seront considérées comme des transactions aux fins de l’article 6.1 du contrat. L’opérateur de registre doit soit (i) enregistrer ces noms par l’intermédiaire d’un bureau d’enregistrement accrédité par

l’ICANN, soit (ii) s’autoattribuer ces noms, soumettre ces noms à l’ICANN et être responsable à l’égard de l’ICANN de leur conformité aux politiques de consensus de l’ICANN et aux obligations prévues dans les paragraphes 3.7.7.1 à 3.7.7.12 du RAA alors en vigueur (ou de toute autre clause de

remplacement fixant les modalités du contrat d’enregistrement entre un

bureau d’enregistrement et un titulaire de nom enregistré). Si l’opérateur de registre choisit l’option (ii) ci-dessus, il devra identifier ces transactions à l’aide de l’ID de bureau d’enregistrement 9998. À la discrétion de l’opérateur de registre et dans le respect de toutes les autres dispositions du présent contrat, y compris les RPM spécifiés dans la spécification 7, ces noms peuvent être débloqués à des fins d’enregistrement par une autre personne ou entité.

3.3. L’opérateur de registre peut exclure de l’enregistrement ou attribuer au registre de l’opérateur des noms (y compris leurs variantes IDN, le cas échéant) à tous les niveaux, conformément à l’article 2.6 du contrat. Ces

noms ne peuvent être activés dans le DNS, mais ils peuvent être débloqués à des fins d’enregistrement par l’opérateur de registre ou toute autre personne ou entité à la discrétion de l’opérateur de registre, sous réserve du respect de toutes les dispositions du présent contrat, y compris les RPM applicables prévus à la spécification 7. Une fois qu’un opérateur de registre est désigné pour exploiter un TLD, tous ces noms qui sont exclus de l’enregistrement ou attribués à l’opérateur de registre devront être transférés, tel que spécifié par l’ICANN. À la demande de l’ICANN, l’opérateur de registre doit fournir une liste de tous les noms exclus ou attribués à l’opérateur de registre, conformément à l’article 2.6 du contrat. L’opérateur de registre peut s’autoattribuer et renouveler ces noms sans utiliser un bureau

d’enregistrement accrédité par l’ICANN, ce qui ne sera pas considéré comme une transaction aux fins de l’article 6.1 du contrat.

3.4. À l’issue de la période de non-activation prévue à l’article 6.1 de la spécification 6, l’opérateur de registre devra attribuer le nom de domaine

« icann-sla-monitoring.<tld> » au bureau d’enregistrement réalisant les tests pour l’ICANN (tel que décrit à l’article 8.2 de la spécification 10). Si ce nom de domaine n’est pas mis à disposition à des fins d’enregistrement dans le TLD ou s’il est par ailleurs incompatible avec les politiques d’enregistrement du TLD, l’opérateur de registre peut attribuer un nom de domaine différent au bureau d’enregistrement réalisant les tests pour l’ICANN, en consultation avec l’ICANN. L’attribution d’un tel nom de domaine alternatif sera communiquée à l’ICANN suite à la consultation. L’attribution du nom de domaine « icann-sla-monitoring.<tld> » au bureau d’enregistrement réalisant les tests pour l’ICANN (i) ne sera pas considérée comme une transaction aux fins de l’article 6.1 du contrat, (ii) ne sera pas comptabilisée comme l’un des cent noms de domaine mis à la disposition de l’opérateur de registre en vertu de l’article 3.2 de la présente spécification 5, et (iii) ne nuira pas à la qualification de l’opérateur de registre en tant que TLD de marque conformément à la spécification 13 (dispositions relatives aux TLD de marques) ci-après (le cas échéant).

4. Noms de pays et de territoires. Les noms de pays et de territoires (y compris leurs variantes IDN, le cas échéant) figurant sur les listes internationalement reconnues

suivantes seront exclus de l’enregistrement ou attribués à l’opérateur de registre à

tous les niveaux :

4.1. la forme courte (en anglais) de tous les noms de pays et de territoires figurant sur la liste ISO 3166-1, telle qu’occasionnellement mise à jour , y compris l'Union européenne qui est à titre exceptionnel réservée sur la liste ISO 3166-1 et son champ d'application étendu en août 1999 à toute application devant représenter le nom de l'Union européenne xxxxx://xxx.xxx.xxx/xxx-0000-xxxxxxx-xxxxx.xxxx ;

4.2. le groupe d’experts des Nations Unies sur les noms géographiques, le manuel de référence technique pour la normalisation des noms géographiques, partie III, noms des pays du monde ; et

4.3. la liste des États membres des Nations Unies, dans les 6 langues officielles, préparée par le Groupe de travail sur les noms de pays de la conférence des Nations Unies sur la normalisation des noms géographiques ;

à condition que la réservation de noms de pays et de territoires spécifiques (y compris leurs variantes IDN selon la politique d’enregistrement d’IDN de l’opérateur de registre, le cas échéant) puisse être débloquée dans la mesure où l’opérateur de registre parvient à un accord avec le ou les gouvernements concernés. L’opérateur de registre ne doit pas activer ces noms dans le DNS, à condition que l’opérateur de

registre puisse proposer de débloquer ces réservations, sous réserve de l’examen du Comité consultatif gouvernemental de l’ICANN et de l’approbation de l’ICANN. Une fois qu’un opérateur de registre est désigné pour exploiter un TLD, tous ces noms qui sont exclus de l’enregistrement ou attribués à l’opérateur de registre devront

être transférés, tel que spécifié par l’ICANN. L’opérateur de registre peut

s’autoattribuer et renouveler ces noms sans utiliser un bureau d’enregistrement accrédité par l’ICANN, ce qui ne sera pas considéré comme une transaction aux fins de l’article 6.1 du contrat.

5. Comité international olympique ; Mouvement international de la Croix-Rouge et du Croissant-Rouge. Conformément aux instructions occasionnellement

fournies par l’ICANN, les noms (y compris leurs variantes IDN, le cas échéant) se rapportant au Comité international olympique et au Mouvement international de la Croix-rouge et du Croissant-rouge énumérés sur xxxxx://xxx.xxxxx.xxx/xxxxxxxx- names seront exclus de l’enregistrement ou attribués à l’opérateur de registre au deuxième niveau dans le TLD. D’autres noms du Comité international olympique et du Mouvement international de la Croix-rouge et du Croissant-rouge (y compris leur variantes IDN) pourront être ajoutés à la liste via un préavis de dix (10) jours civils envoyé par l’ICANN à l’opérateur de registre. Ces noms peuvent ne pas être activés dans le DNS et peuvent ne pas être disponibles pour l'enregistrement par des personnes ou entités autres que l'Opérateur de registre. Une fois qu'un Opérateur de registre aura été désigné pour exploiter un TLD, tous les noms ne pouvant être enregistrés ou attribués à l'Opérateur de registre seront transférés, tel que spécifié

par l'ICANN. L’opérateur de registre peut s’autoattribuer et renouveler ces noms sans utiliser un bureau d’enregistrement accrédité par l’ICANN, ce qui ne sera pas considéré comme une transaction aux fins de l’article 6.1 du contrat.

6. Organisations intergouvernementales. Conformément aux indications occasionnellement fournies par l’ICANN, l’Opérateur de registre mettra en place les mécanismes de protection établis par le Conseil d’administration de l’ICANN pour la protection des identificateurs des Organisations intergouvernementales. Une liste des noms réservés au titre du présent article 6 est disponible sur xxxxx://xxx.xxxxx.xxx/xxxxxxxx-xxxxx. D’autres noms (y compris leurs variantes IDN) pourront être ajoutés à la liste via un préavis de dix (10) jours civils envoyé par l’ICANN à l’opérateur de registre. Ces identificateurs d’Organisations

intergouvernementales bénéficiant d’une protection peuvent ne pas être activés

dans le DNS et peuvent ne pas être disponibles pour l’enregistrement par des

personnes ou entités autres que l’Opérateur de registre. Une fois qu’un Opérateur de registre aura été désigné pour exploiter un TLD, tous ces identificateurs protégés seront transférés, tel que spécifié par l’ICANN. L’opérateur de registre peut s’autoattribuer et renouveler ces noms sans utiliser un bureau d’enregistrement accrédité par l’ICANN, ce qui ne sera pas considéré comme une transaction aux fins de l’article 6.1 du contrat.

SPÉCIFICATION 6

SPÉCIFICATIONS RELATIVES À LA CONTINUITÉ ET À L’INTEROPÉRABILITÉ DU

REGISTRE

1. Conformité avec les normes

1.1. DNS. L’opérateur de registre s’engage à respecter les normes RFC existantes et celles qui seront par la suite publiées par le Groupe de travail de génie Internet (IETF), notamment l’ensemble des normes, modifications ou ajouts ultérieurs liés au DNS et aux opérations de serveur de noms, y compris, sans s’y limiter, les normes RFC 1034, 1035, 1123, 1982, 2181, 2182, 3226, 3596, 4343, 5966 et 6891. Les étiquettes DNS peuvent inclure uniquement des tirets à la troisième et quatrième position si elles représentent des IDN valides (tel qu’indiqué ci-dessus) dans leur encodage ASCII (par exemple,

« xn--ndk061n »).

1.2. EPP. L’opérateur de registre s’engage à respecter les normes RFC existantes et celles qui seront par la suite publiées par le Groupe de travail de génie Internet (IETF), notamment l’ensemble des normes, modifications ou ajouts ultérieurs liés à l’approvisionnement et à la gestion des noms de domaine à l’aide du protocole d'avitaillement extensible (EPP) conformément aux

normes RFC 5910, 5730, 5731, 5732 (si l’on utilise des objets hôte), 5733 et 5734. Si l’opérateur de registre met en œuvre un délai de grâce de registre (RGP), il respectera la norme RFC 3915 et ses normes subséquentes. Si l’opérateur de registre requiert l’utilisation de fonctionnalités en dehors des normes RFC EPP de base, il doit documenter les extensions EPP au format avant-projet Internet, dans le respect des directives décrites dans la norme RFC 3735. L’opérateur de registre fournira et mettra à jour la documentation pertinente portant sur toutes les extensions et tous les objets EPP pris en charge par l’ICANN avant le déploiement.

1.3. DNSSEC. L’opérateur de registre doit signer ses fichiers de zone TLD en déployant des extensions de sécurité du système des noms de domaine (les

« DNSSEC »). Dans un souci de clarté, l'opérateur de registre devra signer le fichier de zone de <TLD> et les fichiers de zone utilisés en tant que colle in- bailiwick pour les serveurs DNS du TLD. Pendant la durée du contrat, l’opérateur de registre s’engage à respecter les normes RFC 4033, 4034, 4035, 4509 et leurs normes subséquentes, et à se conformer aux meilleures pratiques décrites dans la norme RFC 6781 et ses normes subséquentes. Si l’opérateur de registre met en œuvre le déni d’existence authentifié haché pour les DNSSEC, il s’engage à respecter la norme RFC 5155 et ses normes subséquentes. L’opérateur de registre doit accepter le matériel de clé publique des noms de domaine enfants de façon sécurisée et selon les meilleures pratiques de l’industrie. L’opérateur de registre s’engage également à publier sur son site web les déclarations de pratiques DNSSEC

(DPS) décrivant les procédures et les contrôles de sécurité critiques pour le stockage, l’accès au et l’utilisation du matériel de clé pour ses propres clés et à garantir l’acceptation du matériel de clé publique des titulaires de noms de domaine. L’opérateur de registre doit publier ses DPS suivant le format décrit dans la norme RFC 6841. La validation DNSSEC doit être active et utiliser l’ensemble de clé de signature de clé de la racine DNS de l’IANA (disponible sur xxxxx://xxx.xxxx.xxx/xxxxxx/xxxxx) en tant qu’ancre de confiance pour les services de registre de l’opérateur de registre qui utilisent les données obtenues par le biais de réponses DNS.

1.4. IDN. Si l’Opérateur de registre propose des Noms de domaine internationalisés (« IDN »), il devra respecter les normes RFC 5890, 5891, 5892, 5893 et les normes subséquentes. L’opérateur de registre s’engage à respecter les directives de l’ICANN en matière d’IDN disponibles sur xxxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxx/xxxxxxxxxxxxxx-xxxxxxxxxx.xxx, celles-ci pouvant être occasionnellement amendées, modifiées ou

remplacées. L’opérateur de registre doit publier et tenir à jour ses tables IDN et les règles d’enregistrement d’IDN dans le référentiel des pratiques

relatives aux IDN de l’IANA.

1.5. IPv6. L’Opérateur de registre sera en mesure d’accepter les adresses IPv6 en tant qu’enregistrements de type glue dans son Système de registre et de les publier dans le DNS. L’Opérateur de registre proposera un transport public sur IPv6 pour au moins deux de ses serveurs de noms du registre répertoriés dans la zone racine avec leurs adresses IPv6 correspondantes enregistrées auprès de l’IANA. L’Opérateur de registre suivra les « Directives opérationnelles de transport du DNS sur IPv6 », telles que décrites dans le BCP 91, ainsi que les recommandations et les considérations décrites dans la norme RFC 4472. L’opérateur de registre proposera, en plus du transport sur IPv4, un transport public sur IPv6 pour ses services d’annuaire de données d'enregistrement tel que défini à la spécification 4 du présent contrat, par exemple, WHOIS (RFC 3912), WHOIS basé sur le web et RDAP. L’Opérateur de registre proposera un transport public sur IPv6 pour son Système de

registre partagé (SRS) à tout Bureau d’enregistrement, au plus tard six (6) mois après la réception de la première demande écrite d’un Bureau

d’enregistrement accrédité gTLD souhaitant exploiter le SRS sur IPv6.

1.6. Base de données de la zone racine de l’IANA. Afin de garantir que les informations faisant autorité sur le TLD restent accessibles au public, l’opérateur de registre présentera une demande de modification à

l’opérateur des fonctions IANA visant à mettre à jour toute URL basée sur le DNS, le WHOIS ou le RDAP obsolète ou inexacte des enregistrements de service de RDAP du TLD. L’opérateur de registre déploiera des efforts commercialement raisonnables pour soumettre une telle demande de modification au plus tard sept (7) jours civils à compter de la date à laquelle cette URL basée sur le DNS, le WHOIS ou le RDAP des enregistrements de

service de RDAP devient obsolète ou inexacte. L’opérateur de registre devra soumettre toutes les demandes de modification conformément aux procédures disponibles sur xxxxx://xxx.xxxx.xxx/xxxxxxx/xxxx.

1.7. Filtrage d’entrées au réseau. L’opérateur de registre devra mettre en œuvre des contrôles de filtrage d’entrées au réseau pour ses services de

registre tel que décrit dans les normes BCP 38 et BCP 84, que l’ICANN mettra également en œuvre.

2. Services de registre

2.1. Services de registre. Les « services de registre » sont, aux fins du contrat, définis comme suit : (a) les services qui constituent des opérations du registre essentielles aux tâches suivantes : la réception de données

provenant des bureaux d’enregistrement concernant l’enregistrement de

noms de domaine et de serveurs de noms ; la fourniture aux bureaux

d’enregistrement d’informations liées aux statuts des serveurs de zone pour le TLD ; la diffusion des fichiers de zone TLD ; le fonctionnement des serveurs DNS de registre ; et la diffusion des coordonnées et autres informations liées aux enregistrements de serveurs de noms de domaine dans le TLD comme l’exige le présent contrat ; (b) d’autres produits ou services que doit fournir l’opérateur de registre du fait de l’établissement d’une politique de consensus telle que définie dans la spécification 1 ; (c) tout autre produit ou service que seul un opérateur de registre est habilité à fournir du fait de son statut d’opérateur de registre ; et (d) les modifications substantielles apportées aux services de registre relevant des points (a), (b) ou (c) ci- dessus.

2.2. Prohibition des caractères génériques. Pour les noms de domaine qui ne sont pas enregistrés ou pour lesquels le titulaire de nom de domaine n’a pas fourni d’enregistrements valides tels que des enregistrements NS devant figurer dans le fichier de zone DNS, ou dont le statut ne leur permet pas

d’être publiés dans le DNS, l’utilisation d’enregistrements de ressources avec caractères génériques DNS, tel que décrit dans les normes RFC 1034 et 4592, ou de toute autre méthode ou technologie permettant de synthétiser des

enregistrements de ressources DNS ou d’utiliser la redirection dans le DNS par le registre, est interdite. Lorsque de tels noms de domaine font l’objet de requêtes, les serveurs de noms faisant autorité doivent renvoyer une réponse

« Erreur de nom » (également appelée NXDOMAIN), RCODE 3, tel que décrit dans la norme RFC 1035 et dans les normes RFC associées. Cette disposition s’applique à tous les fichiers de zone du DNS, à tous les niveaux de

l’arborescence DNS pour lesquels l’opérateur de registre (ou une société affiliée engagée dans la prestation de services d’enregistrement) met à jour des données, organise une telle mise à jour ou perçoit des revenus du fait de cette mise à jour.

3. Continuité du registre

3.1. Haute disponibilité. L’opérateur de registre s’engage à conduire ses opérations en utilisant un réseau et des serveurs redondants géographiquement répartis (offrant notamment une redondance de niveau réseau, une redondance de niveau nœud terminal et la mise en œuvre d’un mécanisme d’équilibrage de la charge, le cas échéant) pour garantir un

fonctionnement continu en cas de défaillance technique (générale ou locale), ou d’événement ou de circonstance extraordinaire échappant au contrôle de l’opérateur de registre. Le département des opérations d’urgence de

l’opérateur de registre doit être disponible à tout moment pour répondre à

des événements extraordinaires.

3.2. Événement extraordinaire. L’opérateur de registre s’engage à déployer des efforts commercialement raisonnables pour rétablir les fonctions critiques du registre dans les vingt-quatre (24) heures suivant la fin d’un événement extraordinaire échappant au contrôle de l’opérateur de registre et rétablir le fonctionnement complet du système dans un délai maximal de quarante-huit

(48) heures suivant la survenue d’un tel événement, en fonction du type de fonction critique concernée. Les interruptions de service dues à un tel événement ne seront pas considérées comme une indisponibilité du service.

3.3. Continuité de l’activité. L’opérateur de registre doit mettre en place un plan de continuité de l’activité qui garantira le maintien des services de registre en cas d’événement extraordinaire échappant au contrôle de l’opérateur de

registre ou de faillite de l’opérateur de registre. Ce plan pourra également désigner un fournisseur de continuité de services de registre. Si un tel plan désigne un fournisseur de continuité de services de registre, l’opérateur de registre doit fournir le nom et les coordonnées dudit fournisseur à l’ICANN. En cas d’événement extraordinaire échappant au contrôle de l’opérateur de registre lors duquel il est impossible de le contacter, l’opérateur de registre

accepte que l’ICANN puisse contacter le fournisseur de continuité de services de registre désigné, le cas échéant. L’opérateur de registre s’engage à conduire des tests de continuité de services de registre au moins une fois par an.

4. Atténuation de l’utilisation malveillante

4.1. Point de contact pour les abus. L’opérateur de registre doit fournir à

l’ICANN et publier sur son site web ses coordonnées exactes, y compris des adresses e-mail et postale valides et le point de contact primaire chargé des questions relatives aux problèmes de comportements malveillants dans le TLD. En outre, il informera immédiatement l'ICANN de tout changement apporté à ces coordonnées.

4.2. Utilisation malveillante des enregistrements orphelins de type glue. L’opérateur de registre doit prendre des mesures pour éliminer les enregistrements orphelins de type glue (tels que définis à xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxxxxxx/xxx000.xxx) lorsqu’il détient la preuve écrite que ces enregistrements sont liés à une conduite malveillante.

5. Périodes d’enregistrement initial et de renouvellement acceptées

5.1. Périodes d’enregistrement initial. Les enregistrements initiaux des noms enregistrés peuvent être effectués dans le registre par incréments d’une (1) année et pour une période maximale de dix (10) ans. Dans un souci de clarté, les enregistrements initiaux des noms enregistrés ne peuvent excéder les dix

(10) ans.

5.2. Périodes de renouvellement. Le renouvellement des noms enregistrés peut être effectué par incréments d’une (1) année pour une période maximale de dix (10) ans. Dans un souci de clarté, le renouvellement des noms enregistrés ne peut dépasser leur période d’enregistrement de plus de dix (10) ans au moment du renouvellement.

6. Gestion de l’occurrence de collisions de noms de domaine

6.1. Période de non-activation. L’opérateur de registre ne doit pas activer de noms dans la zone DNS pour le TLD du registre (sauf dans le cas de « NIC ») jusqu’à 120 jours civils au moins après la date d’entrée en vigueur du présent contrat. L’opérateur de registre peut attribuer des noms (sous réserve du paragraphe 6.2 ci-dessous) au cours de cette période seulement si

l’opérateur de registre s’occupe d’informer clairement les titulaires de noms de domaine de l’impossibilité d’activer des noms jusqu’à la fin de la période de non-activation.

6.2. Évaluation de l’occurrence de collisions de noms de domaine

6.2.1 L’opérateur de registre ne doit pas activer de noms dans la zone DNS pour le TLD du registre si ce n’est en conformité avec une évaluation de l’occurrence de collisions de noms de domaine fournie par l’ICANN concernant le TLD du registre. L’opérateur de registre devra soit (A) mettre en œuvre les mesures d’atténuation décrites dans son évaluation de l’occurrence de collisions de noms de domaine avant d’activer un nom de domaine de second niveau, soit (B) bloquer ces noms de domaine de second niveau pour lesquels les mesures d’atténuation décrites dans l’évaluation de l’occurrence de collisions de noms de domaine n’ont pas été mises en œuvre et procéder à l’activation de noms qui ne sont pas répertoriés dans l’évaluation.

6.2.2 Nonobstant le paragraphe 6.2.1, l’opérateur de registre peut procéder à l’activation de noms dans la zone DNS sans la mise en œuvre des mesures énoncées dans l’article 6.2.1 seulement si (A) l’ICANN détermine que le TLD du registre peut bénéficier de cette voie

alternative à l’activation de noms et (B) l’opérateur de registre bloque tous les noms de domaine de second niveau identifiés par l’ICANN et figurant sur xxxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxxxxx-xxx- media/announcement-2-17nov13-en, cette liste pouvant être occasionnellement modifiée par l’ICANN. L’opérateur de registre peut activer des noms en vertu du présent paragraphe et, par la suite, activer des noms conformément au paragraphe 6.2.1.

6.2.3 Les ensembles de noms soumis à l’atténuation ou au blocage, conformément aux articles 6.2.1 et 6.2.2, seront basés sur l’analyse menée par l’ICANN des informations du DNS, y compris sur les

données « Un jour dans la vie de l'Internet » conservées par le Centre d'analyse et de recherche pour les opérations DNS (DNS-OARC) (xxxxx://xxx.xxx-xxxx.xxx/xxxx/xxxx/xxxx).

6.2.4 L’opérateur de registre peut participer à l’élaboration par la communauté de l’ICANN d’un processus visant à déterminer si ces noms bloqués peuvent être débloqués et de quelle manière.

6.2.5 Si l’ICANN décide que le TLD ne peut bénéficier de la voie alternative à l’activation de noms, l’ICANN peut choisir de ne pas déléguer le TLD en attendant que la dernière évaluation de l’occurrence de collisions de noms de domaine du TLD soit terminée et que toutes les mesures d’atténuation requises aient été prises par l’opérateur de registre.

L’opérateur de registre comprend que les mesures d’atténuation requises par l’ICANN en tant que condition à l’activation de noms dans la zone DNS pour le TLD peuvent inclure, sans s’y limiter, des mesures d’atténuation telles que celles décrites à l’article 3.2 du nouveau plan de gestion de l’occurrence de collisions de noms de domaine des nouveaux gTLD, approuvé par le Comité du programme des nouveaux gTLD (NGPC) du Conseil d’administration de l’ICANN le 7 octobre 2013, qui est disponible sur xxxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxxxxxx/xxxxxxxxxxx- new-gtld-annex-1-07oct13-en.pdf.

6.3. Traitement des signalements de collisions de noms de domaine

6.3.1 Pendant les deux premières années après la délégation du TLD, le département des opérations d’urgence de l’opérateur de registre doit permettre de recevoir des signalements, relayés par l’ICANN, alléguant un préjudice manifestement grave du fait de collisions entraînant un double emploi des noms en dehors du DNS faisant autorité.

6.3.2 L’opérateur de registre doit établir un processus interne de

traitement accéléré des signalements reçus conformément au

paragraphe 6.3.1 en vertu duquel l’opérateur de registre peut, dans la mesure du nécessaire et de ce qui est approprié, supprimer un nom récemment activé de la zone de TLD pendant une période maximale de deux ans afin de permettre à la partie affectée de modifier ses systèmes.

SPÉCIFICATION 7

EXIGENCES MINIMALES S’APPLIQUANT AUX MÉCANISMES DE PROTECTION DES DROITS

1. Mécanismes de protection des droits. L’Opérateur de registre mettra en œuvre et respectera les mécanismes de protection des droits (« RPM ») prévus dans la présente Spécification. L’Opérateur de registre pourra également développer et mettre en œuvre des RPM supplémentaires qui découragent ou empêchent

l’enregistrement de noms de domaines enfreignant les droits légaux d’une autre partie ou portant atteinte à ces derniers. L’Opérateur de registre inclura tous les RPM exigés par la présente Spécification 7 et tout RPM supplémentaire développé et mis en œuvre par l’Opérateur de registre dans le Contrat entre opérateurs de

registre et bureaux d'enregistrement conclu avec des bureaux d’enregistrement accrédités par l’ICANN autorisés à enregistrer des noms dans le TLD. L’opérateur de registre mettra en œuvre, conformément aux exigences qui y sont énoncées, tous les RPM obligatoires énoncés dans le Centre d'échange d'information sur les marques à la date des présentes, ces exigences étant disponibles sur xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxx-xxxxxxxxxxxx (les

« Exigences du Centre d’échange d’information sur les marques »), certains aspects négligeables de ces exigences pouvant être occasionnellement modifiés par l'ICANN.

L’opérateur de registre s’engage à n’autoriser aucun propriétaire de droits de propriété intellectuelle applicables à utiliser un autre service d’agrégation, de

notification ou de validation d’informations de marques commerciales, s’ajoutant ou

se substituant au Centre d'échange d'information sur les marques désigné par l’ICANN. En cas de conflit entre les conditions générales du présent Contrat et les Exigences du Centre d'échange d'information sur les marques, les conditions générales du présent Contrat prévaudront. L’Opérateur de registre conclura un Contrat

entre opérateurs de registre et bureaux d'enregistrement contraignant et exécutoire avec au moins un bureau d’enregistrement accrédité par l’ICANN afin d’autoriser ledit ou lesdits bureaux d’enregistrement à enregistrer des noms de domaine dans le TLD comme suit :

a. si l’opérateur de registre mène un programme de lancement éligible ou est autorisé par l’ICANN à mener un programme de lancement approuvé (tel que ces termes sont définis dans les exigences du Centre d’échange d’information sur les marques), l’opérateur de registre doit conclure un contrat entre opérateur de registre et bureau d'enregistrement contraignant et exécutoire avec au moins un bureau d’enregistrement accrédité par l’ICANN avant l’attribution des noms de domaine en vertu dudit programme de lancement éligible ou programme de lancement approuvé, selon le cas ;

b. si l’opérateur de registre ne mène pas un programme de lancement éligible ou n’est pas autorisé par l’ICANN à mener un programme de lancement approuvé, l’opérateur de registre devra conclure un contrat entre opérateur de registre et bureau d'enregistrement contraignant et exécutoire avec au

moins un bureau d’enregistrement accrédité par l’ICANN au moins trente

(30) jours civils avant la date d’expiration de la période d’enregistrement prioritaire (tel que défini dans les exigences du Centre d’échange

d’information sur les marques) pour le TLD ; ou

c. si le présent contrat contient une spécification 13, l’opérateur de registre devra conclure un contrat entre opérateur de registre et bureau d'enregistrement contraignant et exécutoire avec au moins un bureau d’enregistrement accrédité par l’ICANN avant la date de début des revendications (tel que défini dans la spécification 13).

Aucune disposition de la présente spécification 7 ne limitera ou ne vaudra renonciation à toute autre obligation ou exigence du présent contrat applicable à l’opérateur de registre, y compris l’article 2.9(a) et la spécification 9.

2. Mécanismes de règlement de litiges. L’opérateur de registre respectera les mécanismes suivants de règlement de litiges, ces mécanismes pouvant être occasionnellement révisés :

a. la procédure de règlement de litiges après délégation de marque (PDDRP) et la procédure de règlement de litiges relatifs à des restrictions à

l’enregistrement (RRDRP) adoptées par l’ICANN (publiées sur xxxxx://xxx.xxxxx.xxx/xxxxx et xxxxx://xxx.xxxxx.xxx/xxxxx, respectivement). l’opérateur de registre accepte de mettre en œuvre et de respecter tous les recours imposés par l’ICANN (notamment tout recours raisonnable, y compris, à des fins de clarification, la résiliation du contrat de registre conformément à la section 4.3(e) du contrat) suite à la décision d’un panel PDDRP ou RRDRP, et de se conformer à une telle décision ; et

b. le système uniforme de suspension rapide (ci-après l’« URS ») adopté par l’ICANN, (publié sur xxxxx://xxx.xxxxx.xxx/xxx), y compris la mise en œuvre des décisions prises par les examinateurs URS.

SPÉCIFICATION 8

INSTRUMENT ASSURANT LA CONTINUITÉ DES OPÉRATIONS

1. L’instrument assurant la continuité des opérations devra (a) fournir suffisamment de ressources financières pour garantir la continuité des opérations des fonctions de registre critiques liées au TLD établies à l’article 6 de la spécification 10 du présent contrat pendant une période de trois (3) ans à compter de la résiliation du présent contrat avant ou le jour du cinquième (5e) anniversaire de la date d’entrée en vigueur ou pendant une période d’un (1) an à compter de la résiliation du

présent contrat après le cinquième anniversaire de la date d’entrée en vigueur mais avant ou le jour du sixième (6e) anniversaire de la date d’entrée en vigueur, et (b) prendre la forme soit (i) d’une lettre de crédit stand-by irrévocable, soit (ii) d’un dépôt en espèces irrévocable, ces deux formes devant remplir les conditions établies au point 50(b) de l’annexe au module 2 - questions et critères concernant l’évaluation du guide de candidature tel que publié et complété par l’ICANN avant la date des présentes (intégré via les présentes par renvoi à la présente spécification 8). L’opérateur de registre devra faire de son mieux pour prendre toutes les

mesures nécessaires ou conseillées afin de maintenir en vigueur l’instrument assurant la continuité des opérations pour une période de six (6) ans à compter de la date d’entrée en vigueur, et de faire en sorte que l’ICANN reste le tiers bénéficiaire de celui-ci. Si l'opérateur de registre choisit d'obtenir une lettre de crédit irrévocable, mais le terme requis ci-dessus est introuvable, l'opérateur de registre peut obtenir une lettre de crédit d'une durée d'un an et d'une « disposition à tacite reconduction », fournissant des prorogations annuelles, sans modification, pour un nombre indéfini de périodes supplémentaires jusqu'à ce que la banque émettrice informe l'ICANN de son expiration finale ou jusqu'à ce que l'ICANN publie la lettre de crédit, comme preuve par écrit, si la lettre de crédit répond par ailleurs aux exigences énoncées dans l'article 50(b) de l'annexe au module 2 - questions et critères d'évaluation - du Guide de candidature gTLD, tels que publié et complété par l'ICANN avant ladite date, à condition, toutefois, que si la banque émettrice informe l'ICANN de l'expiration de la lettre de crédit avant le sixième (6e) anniversaire de la date d'entrée en vigueur, la lettre de crédit doit stipuler que l'ICANN est autorisée à prélever des fonds garantis par la lettre de crédit avant ladite expiration. La lettre de crédit doit exiger de la banque émettrice qu’elle donne à l’ICANN un préavis d’au moins trente (30) jours civils informant de ladite expiration ou dudit non-renouvellement. Si la lettre de crédit expire ou est résiliée à tout moment avant le sixième (6e) anniversaire de la date d’entrée en vigueur, l’opérateur de registre devra obtenir un instrument assurant la continuité des opérations de remplacement. L’ICANN peut débloquer des fonds en vertu de la lettre de crédit originale si l’instrument assurant la continuité des opérations de remplacement n’est pas en place avant l’expiration de la lettre de crédit originale.

L’opérateur de registre fournira à l’ICANN des copies des documents finaux relatifs à l’instrument assurant la continuité des opérations et tiendra l’ICANN informée, dans la mesure du raisonnable, des principales évolutions dudit instrument assurant la continuité des opérations. L’opérateur de registre ne devra ni accepter, ni autoriser,

toute modification de l’instrument assurant la continuité des opérations ou de tout document y afférent, ou toute renonciation en vertu dudit instrument ou desdits documents y afférents, sans le consentement préalable écrit de l’ICANN (qui ne doit pas être refusé sans motif raisonnable).

2. Si, nonobstant tous les efforts déployés par l’opérateur de registre afin de satisfaire ses obligations prévues au paragraphe précédent, l’instrument assurant la continuité des opérations expire ou est résilié par un tiers au présent contrat, en tout ou partie, pour tout motif, avant le sixième anniversaire de la date d’entrée en vigueur, l’opérateur de registre devra dans de brefs délais (i) informer l’ICANN de l’expiration ou de la résiliation et des raisons qui l’ont motivée et (ii) prévoir un instrument alternatif fournissant des ressources financières suffisantes afin de garantir la continuité des fonctions de registre critiques liées au TLD établies à

l’article 6 de la spécification 10 du présent contrat pendant une période de trois (3) ans à compter de la résiliation du présent contrat avant ou le jour du cinquième (5e) anniversaire de la date d’entrée en vigueur ou pendant une période d’un (1) an à compter de la résiliation du présent contrat après le cinquième anniversaire de la date d’entrée en vigueur mais avant ou le jour du sixième (6e) anniversaire de la date d’entrée en vigueur (un « Instrument alternatif »). Les conditions d’un tel

instrument alternatif doivent être aussi favorables à l’ICANN que celles de l’instrument assurant la continuité des opérations et le fond et la forme d’un tel

instrument doivent par ailleurs être acceptables pour l’ICANN, dans la mesure du

raisonnable.

3. Nonobstant toute disposition contraire de la présente spécification 8, à tout moment, l’opérateur de registre pourra remplacer l’instrument assurant la continuité des opérations par un instrument alternatif (i) fournissant des ressources financières suffisantes afin de garantir la continuité des fonctions de registre

critiques liées au TLD établies à l’article 6 de la spécification 10 du présent contrat pendant une période de trois (3) ans à compter de la résiliation du présent contrat avant ou le jour du cinquième (5e) anniversaire de la date d’entrée en vigueur ou pendant une période d’un (1) an à compter de la résiliation du présent contrat après le cinquième anniversaire de la date d’entrée en vigueur mais avant ou le jour du sixième (6e) anniversaire de la date d’entrée en vigueur, et (ii) comportant des conditions aussi favorables à l’ICANN que celles de l’instrument assurant la continuité des opérations, le fond et la forme d’un tel instrument devant par ailleurs être acceptables pour l’ICANN, dans la mesure du raisonnable. Si l’opérateur de

registre remplace l’instrument assurant la continuité des opérations conformément soit au paragraphe 2, soit au présent paragraphe 3, les conditions de la présente spécification 8 ne seront plus applicables pour ce qui est de l’instrument assurant la continuité des opérations initial, mais seront applicables audit instrument alternatif, et cet instrument sera par la suite réputé constituer l’instrument assurant la continuité des opérations aux fins du présent contrat.

SPÉCIFICATION 9

CODE DE CONDUITE DE L’OPÉRATEUR DE REGISTRE

1. Concernant l’exploitation du registre pour le TLD, l’opérateur de registre ne devra pas ou n’autorisera aucun parent, aucune filiale, aucune société affiliée, aucun sous- traitant ou aucune entité associée, dans la mesure où une telle partie est engagée dans la fourniture de services de registre à l’égard du TLD (individuellement un

« Tiers associé au registre »), à :

a. directement ou indirectement, manifester une préférence ou assurer un traitement spécial envers un bureau d’enregistrement en ce qui concerne l’accès opérationnel aux systèmes de registre et aux services de registre y

afférents, sauf si des opportunités comparables justifiant une telle préférence ou un tel traitement spécial sont données à tous les bureaux

d’enregistrement dans des conditions sensiblement similaires ;

b. enregistrer des noms de domaine de plein droit, à l’exception des noms enregistrés auprès d’un bureau d’enregistrement accrédité par l’ICANN, à condition, toutefois, que l’opérateur de registre puisse (a) réserver à

l’enregistrement des noms conformément à l’article 2.6 du contrat et (b)

exclure de l’enregistrement ou attribuer à l’opérateur de registre jusqu’à cent

(100) noms conformément à l’article 3.2 de la spécification 5 ;

c. enregistrer des noms dans le TLD ou les sous-domaines du TLD sur la base d’un accès à des informations exclusives concernant les recherches ou les demandes de règlement de litiges par les consommateurs pour des noms de domaine n’étant pas encore enregistrés (communément appelé la

« réservation préventive ») ; ou

d. autoriser tout bureau d’enregistrement affilié à divulguer des données

personnelles des titulaires de noms de domaine à l’opérateur de registre ou à un tiers associé au registre, sauf si cela est raisonnablement nécessaire à des fins de gestion et d’exploitation du TLD, à moins que les tiers non associés (y compris d’autres opérateurs de registre) bénéficient d’un accès équivalent à de telles données de l’utilisateur dans des conditions sensiblement similaires.

2. Si un opérateur de registre ou un tiers associé au registre agit également en tant que fournisseur de services de bureau d’enregistrement ou de bureau d’enregistrement- revendeur, l’opérateur de registre se chargera, ou chargera ledit tiers associé au

registre, d’assurer que ces services sont offerts par l’intermédiaire d’une entité distincte de l’opérateur de registre et de tenir à jour des livres de comptes distincts conformément à ses opérations de bureau d’enregistrement ou de bureau

d’enregistrement-revendeur.

3. Si l’opérateur de registre ou un tiers associé au registre agit également en tant que

fournisseur de services de bureau d’enregistrement ou de bureau d’enregistrement-

revendeur, l’opérateur de registre procédera à des examens internes au moins une

fois par année civile pour assurer le respect de ce code de conduite. Dans un délai de

(20) jours civils suivant la fin de chaque année calendaire, l’opérateur de registre fournira les résultats des examens internes ainsi qu’une certification signée par un membre de la direction de l’opérateur de registre attestant de la conformité de l’opérateur de registre avec ce code de conduite, par courrier électronique à

l’adresse qui sera fournie par l’ICANN. (L’ICANN peut préciser à l’avenir la forme et le contenu de ces rapports ou exiger que les rapports soient livrés par d’autres moyens raisonnables.) L’opérateur de registre convient que l’ICANN peut diffuser publiquement ces résultats et la certification, à condition, toutefois, que l’ICANN ne divulgue pas d’informations confidentielles contenues dans ces résultats, sauf en conformité avec l’article 7.15 du contrat.

4. Aucune disposition des présentes ne doit : (i) empêcher l’ICANN de mener des enquêtes en cas de réclamation pour non-conformité de l’opérateur de registre avec ce code de conduite ; ou (ii) constituer des motifs de refus de coopération de

l’opérateur de registre dans le cadre des enquêtes de l’ICANN en cas de réclamation

pour non-conformité de l’opérateur de registre avec ce code de conduite.

5. Aucune disposition des présentes ne doit empêcher l’opérateur de registre ou tout tiers associé au registre de conclure des transactions dans des conditions de pleine concurrence dans le cadre d’activités normales menées avec un bureau

d’enregistrement ou un revendeur eu égard à des produits et des services

aucunement associés au TLD.

6. L’opérateur de registre peut demander une dérogation à ce code de conduite, et ladite dérogation peut être accordée par l’ICANN à sa discrétion raisonnable, si l’opérateur de registre démontre à la satisfaction raisonnable de l’ICANN que (i) tous les enregistrements de noms de domaine dans le TLD sont enregistrés et maintenus par l’opérateur de registre à l’usage exclusif de l’opérateur de registre ou de ses sociétés affiliées, (ii) l’opérateur de registre ne vend pas, ne distribue pas et ne transfère pas le contrôle ou l’utilisation d’enregistrements dans le TLD à un tiers qui n’est pas une société affiliée de l’opérateur de registre, et (iii) l’application de ce code de conduite au TLD n’est pas nécessaire pour protéger l’intérêt public.