CONTRAT DE REGISTRE

CONTRAT DE REGISTRE

Ce CONTRAT DE REGISTRE (« contrat ») est conclu à partir de __ (« 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 à but non lucratif (« ICANN »), et

un _ (« opérateur de registre »).

CHAPITRE 1.

DÉLÉGATION ET FONCTIONNEMENT DES DOMAINES DE PREMIER NIVEAU ; AFFIRMATIONS ET GARANTIES

1.1 Domaine et désignation. Le domaine de premier niveau concerné par ce contrat est __ _ (le « TLD »). A la date d’entrée en vigueur et jusqu’à l'expiration de la période définie dans l'article 4.1, ou la résiliation du présent contrat conformément au chapitre 4, 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 favorisé et continue à promouvoir 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 (ISP) et des hébergements Internet 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 Affirmations et garanties.

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

(i) Toutes les informations substantielles fournies et les déclarations faites lors de la candidature pour le registre TLD ainsi que les déclarations par écrit faites lors des négociations du présent contrat étaient vraies et exactes à ce moment-là et de telles informations et déclarations

continuent d’être vraies et exactes à tous points de vue substantiels à 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 organisé, jouit d’une bonne réputation et existe conformément aux lois de la juridiction indiquée dans le préambule de ce document, et l’opérateur de registre détient les pouvoirs et l’autorité nécessaires et a obtenu toutes les approbations requises pour participer et exécuter le présent contrat ; et

(iii) L’opérateur de registre a remis à l’ICANN un instrument dûment exécuté qui garantit les 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 d’opérations continues») et un tel instrument est une obligation qui lie les parties et qui est donc exécutable selon ses conditions.

(b) L’ICANN affirme et garantit à l’opérateur de registre que l’ICANN est une société à but non lucratif dûment organisée, validement fondée, de bonne réputation et conforme aux lois de l’État de la Californie, États-Unis. L’ICANN a le pouvoir et l’autorité nécessaires et a obtenu toutes les approbations d’entreprise nécessaires pour participer et dûment exécuter le présent contrat.

CHAPITRE 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 à ces présentes (« spécification 6 ») et tout autre service de registres décrit à la pièce A (collectivement, les «services approuvés»). Si l’opérateur de registre désire fournir tout autre service de registre qui n’est pas un service approuvé ou qui est une modification matérielle d’un service approuvé (un « service supplémentaire », chacun), l’opérateur de registre présentera une demande d’approbation pour un tel service supplémentaire selon la politique d’évaluation des services de registre au xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/xxxx.xxxx, tel que ladite politique peut être amendée de temps à autre conformément aux règlements de l’ICANN

(tels qu’amendés de temps à autre, les « statuts de l’ICANN ») applicables aux politiques consensuelles (la « RSEP »). L'opérateur de registre peut offrir des services complémentaires seulement avec l'approbation écrite de l'ICANN et, pour toute autre approbation de la sorte, lesdits services complémentaires seront considérés comme des services de registre dans le cadre de ce contrat. À sa discrétion, l’ICANN peut exiger un amendement au présent contrat reflétant la fourniture de tout service supplémentaire approuvé selon la RSEP. La forme de cet amendement sera raisonnablement acceptable par les parties.

2.2 Conformité avec les politiques consensuelles et les politiques provisoires. L’opérateur de registre doit appliquer et être conforme à toutes les politiques consensuelles et politiques provisoires incluses dans la page

<xxxx://xxx.xxxxx.xxx/xxxxxxx/xxxxxxxxx-xxxxxxxx.xxx>, à compter de la date d’entrée en vigueur, et pouvant être élaborées et adoptées par la suite conformément aux statuts de l'ICANN à condition que ces politiques consensuelles et ces politiques provisoires futures soient adoptées conformément à la procédure et aient trait à ces sujets, sous réserve des restrictions prévues à la spécification 1 jointe à ces présentes (« spécification 1 »).

2.3 Dépôt de données. L’opérateur de registre devra être conforme aux procédures de dépôt de données des registres définies à la spécification 2 jointe à ces présentes (« spécification 2 »).

2.4 Élaboration de rapports mensuels. Dans les vingt (20) jours civils suivant la fin de chaque mois civil, l’opérateur de registre devra envoyer à l’ICANN un rapport dans le format indiqué dans la spécification 3 jointe à ces présentes (« spécification 3 »).

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 à ces présentes (« spécification 3 »).

2.6 Noms réservés. Sauf dans la mesure où l’ICANN l’autoriserait expressément par écrit, l’opérateur de registre devra se conformer aux exigences établies dans la spécification 5 jointe à ces présentes (« 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 pour réserver (p. ex., refuser l'enregistrement ou attribuer à l'opérateur de registre, mais pas enregistrer des tiers, déléguer, utiliser, activer dans le DNS ou rendre disponible de toute autre façon) ou bloquer des chaînes de caractères supplémentaires dans le TLD à sa discrétion. Sauf pour ce qui est é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 qu'elles sont définies à l'article 6.1) aux fins du calcul des frais de transaction au titre du registre que l'opérateur de registre devra payer à l'ICANN conformément à l'article 6.1.

2.7 Spécifications fonctionnelles et d’exécution. L'opérateur de registre devra se conformer aux spécifications relatives à l'interopérabilité et la continuité du registre, prévues dans la spécification 6 jointe à ces présentes (« 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 de lancement du TLD ainsi qu’une protection continue des droits d’autrui et une protection relative à l’enregistrement initial tel que décrit dans la spécification 7 jointe à ces présentes (« spécification 7 »). L’opérateur de registre peut, à son choix, mettre en œuvre des protections supplémentaires des droits d’autrui reconnus par la loi. Toute modification ou tout changement des processus et

procédures requis par la spécification 7 suivant la date d’entrée en vigueur devront être préalablement acceptés par l’ICANN par écrit. L’opérateur de registre doit respecter tous les remèdes 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 les remèdes tel qu’exposé dans la procédure applicable décrite dans ces présentes. L’opérateur de registre devra prendre des mesures raisonnables pour examiner et répondre à tous rapports des organismes d’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 obligé 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 faits par l'intermédiaire d'un bureau d'enregistrement accrédité par l'ICANN ; à

condition que cet opérateur de registre n'ait pas besoin de se servir d'un bureau d'enregistrement s'il enregistre des noms en son nom propre afin de refuser ces noms pour leur délégation ou leur utilisation, suivant 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 font partie et qui sont en conformité avec le contrat entre le registre et le bureau d'enregistrement pour le TLD ; à condition que l'opérateur de registre puisse établir des critères non discriminatoires afin de qualifier pour enregistrer des noms dans le TLD qui soient raisonnablement liés au fonctionnement approprié 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

registre-bureau d’enregistrement ». L'opérateur de registre peut modifier le contrat entre le registre et le bureau d'enregistrement de temps à autre ; sous réserve que toute révision matérielle y afférente soit cependant approuvée par l'ICANN avant que ces révisions ne prennent effet et qu'elles ne deviennent contraignantes pour tout bureau d'enregistrement. L'opérateur de registre enverra un avis écrit concernant toute révision du contrat entre l'opérateur de registre et le bureau d'enregistrement à l'ICANN et à tous les bureaux d'enregistrement autorisés à enregistrer des noms dans le TLD avec un minimum de quinze (15) jours civils, avant que lesdites révisions ne prennent effet et qu'elles ne deviennent contraignantes pour tout bureau d'enregistrement. Pendant cette période, l'ICANN déterminera si ces propositions de révision sont négligeables, potentiellement importantes ou importantes. Si l'ICANN ne notifie pas l'opérateur de registre de sa détermination dans ce délai de quinze 15 (quinze) jours civils, il faudra considérer que l'ICANN a déterminé que les révisions proposées n'étaient pas substantielles. Si l'ICANN détermine, ou si l'on estime qu'elle a déterminé suivant cet article 2.9, que lesdites révisions ne sont pas substantielles, l'opérateur de registre peut alors adopter et mettre en œuvre ces révisions. Si l'ICANN détermine que les révisions mentionnées sont substantielles ou potentiellement substantielles, elle suivra alors sa procédure concernant la révision et l'approbation de changements apportés aux contrats entre les registres et les bureaux d'enregistrement, telle que publiée dans

<xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxx-xxxxxxxxx-xxxxxxxxx>, et lesdites révisions ne seront pas adoptées ni mises en œuvre jusqu'à ce qu'elles soient approuvées par l'ICANN.

(b) Si l'opérateur de registre (i) devient affilié ou revendeur d'un bureau d'enregistrement accrédité par l'ICANN, ou (ii) qu'il sous-traite l'approvisionnement de n'importe quel service de registre à un bureau d'enregistrement accrédité par l'ICANN, à un revendeur de bureau d'enregistrement ou n'importe lequel de leurs affiliés respectifs, alors, qu'il s'agisse des cas (i) ou (ii) mentionnés ci-dessus, l'opérateur de registre notifiera l'ICANN, dans les plus brefs délais, du contrat, de la transaction ou de tout autre accord relatifs à cette affiliation, à cette relation avec un revendeur ou sous-contrat, selon le cas, y compris, si l'ICANN le demande, la présentation de copies de tout contrat y afférentes, à condition que l'ICANN traitera ledit contrat ou les documents y afférents adéquatement marqués comme confidentiels (tel que défini dans l'article 7.15) comme une information confidentielle de l'opérateur de registre suivant l'article 7.15 (sauf que l'ICANN puisse divulguer ce contrat et les documents y afférents aux autorités de concurrence

compétentes). L’ICANN se réserve le droit, mais pas l’obligation de renvoyer un tel contrat, les documents y afférents, la transaction ou autre disposition aux autorités de concurrence compétentes au cas où l’ICANN déterminerait qu’un tel contrat, les documents y afférents, la transaction ou autre disposition peut soulever des questions de concurrence significatives en vertu de la loi applicable.. Si cela était faisable et approprié suivant les circonstances, l'ICANN donnera à l'opérateur de registre un avis préalable dudit renvoi aux autorités de concurrence compétentes.

(c) Aux fins du présent contrat : (i) « affilié » signifie 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é par » et « sous contrôle commun avec ») signifie la possession, directement ou indirectement, du pouvoir de diriger ou de provoquer la

direction de la gestion ou des politiques d’une personne ou d’une entité, que ce soit par la possession de titres de placement, en tant que fiduciaire ou liquidateur, par le fait d’être employé ou membre d’un conseil d’administrateur ou autre organe équivalent, par contrat, par accord de crédit 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 présenter à l'ICANN et à chaque bureau d’enregistrement

accrédité par l’ICANN ayant exécuté le contrat registre-bureau d’enregistrement pour le TLD, en signalant au préalable par écrit toute augmentation de prix (y compris celle résultant de l’élimination de tous remboursements, rabais, remises, lien pour produit 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, liens pour produits ou autres programmes était clairement limitée et visiblement indiquée au bureau d’enregistrement lorsqu’ils sont offerts) au moins trente (30) jours civils auparavant.

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 de un (1) à dix (10) ans à la discrétion du bureau d’enregistrement, les périodes ne pouvant pas toutefois 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 présenter à l'ICANN et à chaque bureau

d’enregistrement accrédité par l’ICANN ayant exécuté le contrat registre-bureau d’enregistrement pour le TLD, en signalant au préalable par écrit toute augmentation de prix (y compris celle résultant de l’élimination de tous remboursements, rabais, remises, lien pour produit , programmes de marketing qualifiés ou tout autre programme ayant pour effet de réduire le prix facturé aux bureaux d’enregistrement) au moins cent quatre-vingt (180) jours civils auparavant. Nonobstant ce qui a été mentionné, en ce qui concerne le renouvellement d’enregistrements de noms de domaine : (i) l’opérateur de

registre doit seulement fournir un avis de trente (30) jours civils pour toute augmentation de prix 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 de cet article 2.10(b) au cours des douze (12) mois précédant la date effective de l'augmentation de prix proposée , et (ii) l’opérateur de registre ne doit pas fournir d’avis d’augmentation de prix pour l’imposition de frais variables de niveau de registre décrits dans 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 place avant toute augmentation annoncée) pour des périodes de 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 avoir des prix uniformes pour les renouvellements des enregistrements de noms de domaine (« prix de renouvellement »). Dans le but de fixer les prix de renouvellement, le prix pour chaque renouvellement d’enregistrement de nom de domaine doit être identique au prix du renouvellement de tous les autres enregistrements de noms de domaine existants au moment dudit renouvellement, et ce prix doit prendre en compte l’application universelle de tous remboursements, rabais, remises, liens à des produits ou autres programmes en place au moment du renouvellement. Les exigences de cet article 2.10 ne seront pas applicables pour (i) fixer le prix de renouvellement si le bureau d’enregistrement a fourni à 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 suite à une divulgation 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 au programme de marketing qualifié (tel que défini ci-dessous). Les parties reconnaissent que l'objet de cet 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 domaine et que cet article 2.10(c) devra être généralement interprété comme interdisant de telles pratiques. Aux fins de cet article 2.10(c), un « programme de marketing qualifié » est un programme de marketing selon lequel l’opérateur de registre offre une fixation de prix de renouvellement réduite, à condition que chacun des critères suivants soit satisfait : (i) le programme et les réductions concernées soient offerts pour une période ne dépassant pas les cent quatre-vingt (180) jours civils (avec les programmes consécutifs similaires regroupés dans le but de déterminer le nombre de jours civils du programme), (ii) tous les bureaux d'enregistrement accrédités par l'ICANN aient la même opportunité pour pouvoir demander le prix de renouvellement réduit ; et (iii) l’intention ou l’effet du programme ne soit pas d’exclure une ou plusieurs

catégories spécifiques d’enregistrements (par ex. les enregistrements détenus par de grandes sociétés) ou d’augmenter le prix de renouvellement d’une ou de plusieurs

catégories spécifiques d’enregistrements. Rien dans cet article 2.10(c) ne limitera les obligations de l'opérateur de registre conformément à ce qui est établi à 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’autre termes, gérer les serveurs de zone TLD du registre) à ses propres frais.

2.11 Audits contractuels et opérationnels de conformité.

(a) L’ICANN peut de temps en temps (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 avec ses affirmations et garanties définies dans le chapitre 1 du présent contrat et ses engagements définis 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 en détail 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 ouvrables normales de manière à ne

pas perturber de manière non raisonnable le fonctionnement des opérations de l’opérateur de registre. Dans le cadre d’un tel contrôle 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. Après un préavis d’au moins dix (10) jours ouvrables (sauf convenu 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 ouvrables normales afin de vérifier la conformité de l'opérateur de registre avec ses affirmations et garanties définies dans le chapitre 1 du présent contrat et ses engagements définis dans le chapitre 2 du présent contrat. L'ICANN traitera toute information obtenue concernant ces audits et ayant été classée comme confidentielle (suivant les exigences de l'article 7.15) comme information confidentielle 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é ou ne soit sous contrôle commun ou ne soit autrement affilié à un bureau d’enregistrement accrédité par l’ICANN ou un revendeur de bureau d’enregistrement ou un de leurs affiliés respectifs, 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 à un de leurs affiliés respectifs, et que dans l’un des cas (A) ou (B) ci-dessus, que l’audit n’ait rapport à la conformité de l’opérateur de registre à l'article 2.14, auquel cas l’opérateur de registre devra rembourser l’ICANN pour tous les coûts et dépenses raisonnables associés à la partie de l’audit ayant rapport à la conformité de l’opérateur de registre avec l'article 2.14, ou (ii) l’audit ne soit réalisé en raison de différences dans les frais payés par l’opérateur de registre, ces frais représentant plus de 5 % dans un trimestre donné au

détriment de l’ICANN. Dans ce cas, l’opérateur de registre devra rembourser l’ICANN pour tous les coûts et dépenses raisonnables associés à la totalité d’un tel audit. Dans l’un des cas (i) ou (ii) ci-dessus, ce remboursement sera payé avec le prochain paiement des frais de niveau de registre après la date de transmission de la déclaration des coûts pour l’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 affirmations et garanties définies dans le chapitre 1 du présent contrat ou ses engagements définis dans le chapitre 2 du présent contrat dans le cadre de deux audits consécutifs réalisés conformément à l'article 2.11, l’ICANN peut augmenter le nombre de ces audits à un audit par trimestre civil.

(d) (d) L’opérateur de registre préviendra immédiatement l’ICANN du démarrage de l’une quelconque des procédures mentionnées dans l'article 4.3(d) ou de l’occurrence de l’une des affaires spécifiées dans l'article 4.3(f).

2.12 Instrument d’opérations continues. L’opérateur de registre doit respecter les conditions portant sur l’instrument d’opérations continues décrit dans la spécification 8 jointe à ces présentes (« spécification 8 »).

2.13 Transition en cas d’urgence. L’opérateur de registre accepte qu'au cas où les seuils d'urgence pour les fonctions de registre établis dans 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 de registre de l’ICANN (disponible sur

<xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxxxx-xxxxxxxxx>) (tel que celui-ci pourra être amendé à tout moment, ci-après le « processus de transition de registre ») jusqu’au moment où l’opérateur de registre aura démontré raisonnablement, à la

satisfaction de l’ICANN, qu’il peut reprendre la gestion du registre pour le TLD sans qu’un tel défaut ne se reproduise. Suite à cette démonstration, l’opérateur de registre peut suivre la transition inverse vers l’exploitation du registre pour le TLD conformément aux procédures définies dans le processus de transition de registre, à condition que l’opérateur de registre paie tous les frais raisonnables encourus (i) par l’ICANN comme résultat de la désignation de l’opérateur d’urgence et (ii) par l’opérateur d’urgence en rapport avec l’exploitation du registre pour le TLD, les frais devant être justifiés suffisamment en détail dans les livres qui seront mis à la 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 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 à maintenir les opérations et les fonctions de registre pouvant être requises raisonnablement 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’il jugera nécessaires à la base de données IANA pour les enregistrements du DNS et du WHOIS concernant le TLD en cas de désignation d’un Opérateur d’urgence conformément au présent article 2.13. En outre, si cette défaillance se produisait, l’ICANN conservera et pourra appliquer ses droits en vertu de l’instrument assurant la continuité des opérations.

2.14 Code de conduite du registre. Au sujet du fonctionnement du registre pour le TLD, l’opérateur de registre doit se conformer au code de conduite des registres tel qu'il est établi dans la spécification 9 jointe à ces présentes (« spécification 9 »).

2.15 Coopération aux les études économiques. Si l'ICANN commence 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 points connexes, l'opérateur de registre devra raisonnablement collaborer dans la réalisation de cette étude, y compris en remettant à l'ICANN ou à son représentant dirigeant 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, sous réserve 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 à ces données-là et (b) toute donnée dans la mesure où la présentation desdites données constituerait une violation aux lois en vigueur. Toute donnée remise à l'ICANN ou à son représentant conformément à cet article 2.15 qui soit marquée comme confidentielle de manière adéquate (tel qu'exigé par l'article 7.15) devra être traitée comme information confidentielle de l'opérateur de registre en vertu de l'article 7.15, à condition que si l'ICANN regroupe et rend anonymes lesdites données, l'ICANN ou son représentant pourront 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 rendues anonymes.

2.16 Spécifications de performance du registre. Les spécifications d’exécution du registre pour le fonctionnement du TLD seront celles étant établies dans la spécification 10 jointe à ces présentes (« spécification 10 »). L’opérateur de registre devra se conformer à ces spécifications d’exécution et, pendant une période d'au moins un (1) an, devra maintenir des enregistrements techniques et fonctionnels suffisants pour prouver la conformité à ces spécifications pour chaque année civile de la durée de validité du contrat.

2.17 Engagements d'intérêt public supplémentaires. Les spécifications fonctionnelles et d’exécution pour le fonctionnement du TLD seront telles qu’exposées dans la spécification 11 jointe à ces présentes (« 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 et faisant partie d'un contrat

registre-bureau d'enregistrement pour le TLD aux fins duquel les données concernant toute personne physique identifiée ou identifiable (« données personnelles ») soumises à l'opérateur de registre par ledit bureau d'enregistrement sont collectées et utilisées dans le cadre de ce contrat ou autrement et aux destinataires (ou aux 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 mentionnées des données personnelles. L'opérateur de registre prendra toutes les mesures raisonnables pour protéger les données personnelles collectées dudit bureau d'enregistrement contre la perte, l'usage frauduleux, la divulgation non autorisée, l'altération ou la destruction. L'opérateur de registre n'utilisera ni n'autorisera l'utilisation des données personnelles de manière incompatible avec la notification faite aux bureaux d'enregistrement.

2.19 [Remarque : À l'attention des TLD communautaires uniquement] Obligations de l'opérateur de registre envers la communauté du 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 d'attribution de noms dans le TLD,

(ii) les conditions d'enregistrement des membres de la communauté TLD, et (iii) l'utilisation des noms de domaine enregistrés conformément à l'objectif énoncé du TLD communautaire. L'opérateur de registre doit gérer le TLD de manière à ce que la

communauté puisse discuter et participer à l’élaboration et à la modification des politiques et des pratiques relatives au TLD. L'opérateur de registre devra établir des procédures pour l'application des politiques du TLD et de règlement des différends concernant la conformité avec les politiques d'enregistrement du TLD et sera responsable de leur

application. 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 décrite à xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx quant aux litiges résultants

conformément au présent article 2.19. L'opérateur de registre mettra en œuvre et agira conformément aux politiques d'enregistrement communautaires établies à la spécification 12 jointe à ces présentes.

CHAPITRE 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 ou 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 ou raisonnable.

3.3 Serveurs de noms TLD. L’ICANN déploiera des efforts raisonnables à l'échelle commerciale 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 d’après les éléments techniques exigés par l’ICANN sur xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/)

soient 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 informations de contact de la zone racine pour le TLD inclura 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 défini de temps en temps 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 était autorisée à définir des politiques concernant un système de serveurs racine faisant

autorité (le « système du serveur racine faisant autorité »), l’ICANN fera des efforts raisonnables à échelle commerciale 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) maintiendra une base de données stable, sécurisée et officielle publiquement disponible comportant les informations pertinentes sur le TLD,

conformément aux politiques et procédures de l’ICANN publiquement disponibles, et (c) coordonnera le système de serveurs racine 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 de ce contrat et que l’ICANN ne soit pas responsable au cas où une partie tierce (y compris toute entité gouvernementale ou tout fournisseur de services Internet) bloquerait ou limiterait l’accès au TLD dans toute juridiction.

CHAPITRE 4.

DURÉE ET RÉSILIATION

4.1 Durée. La durée de ce 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) Ce 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 adressé à l’opérateur de registre concernant une infraction substantielle et fondamentale des engagements de l’opérateur de registre établis au chapitre 2 ou à un manquement à ses obligations de paiement établies au chapitre 6 de ce contrat. Un tel avis doit

inclure les détails du manquement présumé et si ce manquement n’est pas réparé dans les trente (30) jours civils suivant l’avis, (A) un arbitre ou une cour de justice a finalement décidé que l’opérateur de registre a enfreint de façon substantielle et fondamentale à ses engagements ou est en manquement à ses obligations de paiement, et (B) l’opérateur de registre ne s’est pas conformé à la décision et n’a pas remédié au manquement dans les dix (10) jours civils ou toute autre période définie par l’arbitre ou la cour de justice ; ou si

(ii) pendant la durée actuelle du contrat, un arbitre ou un tribunal de la juridiction compétente vérifiait que l’opérateur de registre (en vertu de l'article 5.2 du présent contrat) a contrevenu, au moins à trois (3) occasions différentes et (A) de manière fondamentale (qu’il ait remédié ou non au manquement) à ses engagements établis au chapitre 2 ou (B) qu’il a manqué à ses obligations de paiement selon le chapitre 6 du présent contrat.

(b) Si les événements décrits à l'article 4.2(a)(i) ou (ii) se produisaient, 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, suite à un préavis adressé à l’opérateur de registre, résilier ce contrat si : (i) l’opérateur de registre ne remédie pas à (A) tout manquement

fondamental et substantiel quant aux affirmations et garanties établies au chapitre 1 ou aux engagements de l’opérateur de registre établis au chapitre 2 ou à (B) tout manquement aux obligations de paiement de l’opérateur de registre établies au chapitre 6 du présent contrat et ce, dans les trente (30) jours suivant le préavis adressé par l’ICANN à l’opérateur de registre sur le manquement en question, le préavis devant préciser les détails du manquement présumé, (ii) un arbitre ou un tribunal de la juridiction compétente a

finalement décidé que l’opérateur de registre a contrevenu de manière fondamentale et substantielle à ses engagements ou est en manquement à ses obligations de paiement et

(iii) l’opérateur de registre ne s’est pas conformé à la décision et n’a pas remédié au manquement dans les dix (10) jours civils ou toute période définie par l’arbitre ou le tribunal compétent.

(b) L’ICANN peut, suite à un préavis adressé à l’opérateur de registre, résilier ce contrat si l’opérateur de registre ne complétait pas tous les essais et procédures (identifiés par l’ICANN par écrit avant cette date) pour la délégation du TLD dans la zone racine dans un délai de douze (12) mois suivant la date d’entrée en vigueur. L’opérateur de registre peut demander une prolongation de 12 mois maximum s’il apporte la preuve, à la satisfaction de l’ICANN et dans la mesure du raisonnable, de son application et de sa bonne foi dans la réalisation des étapes nécessaires à la délégation du TLD. L'ICANN gardera la totalité des frais payés par l’opérateur de registre à l’ICANN avant cette résiliation.

(c) L’ICANN peut, suite à un préavis adressé à l’opérateur de registre, résilier ce contrat si (i) l’opérateur de registre ne remédiait pas à un manquement substantiel aux obligations d’opérateur de registre définies à l'article 2.12 du présent

contrat, dans un délai de trente (30) jours civils suivant le préavis de l’ICANN quant au manquement en question ou, si l’instrument d’opérations continues n’était pas en place pendant plus de soixante (60) jours civils consécutifs à un moment quelconque suivant la date d’entrée en vigueur, (ii) un arbitre ou un tribunal de juridiction compétente avait

finalement décidé que l’opérateur de registre est en manquement substantiel à de tels engagements, et (iii) l’opérateur de registre ne remédiait pas au manquement en question dans un délai de dix (10) jours civils ou toute autre période éventuellement définie par l’arbitre ou le tribunal de juridiction compétente.

(d) L’ICANN peut, suite à un préavis adressé à l’opérateur de registre, résilier ce contrat si (i) l’opérateur de registre procédait à une cession en faveur de ses créditeurs ou à une action similaire, (ii) une procédure de saisie-exécution, saisie-arrêt ou similaire était engagée contre l’opérateur de registre, dont le procès constitue une menace substantielle pour la capacité de l’opérateur de registre en termes d’exploitation du registre pour le TLD et qui n’est pas rejetée dans les soixante (60) jours civils à compter de son initiation, (iii) un fidéicommissaire, un curateur, un liquidateur ou équivalent était affecté à la place de l’opérateur de registre ou maintenait le contrôle sur les biens de l’opérateur de registre, (iv) une poursuite par voie de saisie était imposée sur des biens de

l’opérateur de registre, (v) des procédures étaient engagées par ou contre l’opérateur de registre au titre des lois régissant la faillite, l’insolvabilité, la réorganisation ou autres pour le remboursement de débiteurs et de telles procédures ne sont pas rejetées dans les trente

(60) jours civils à compter de leur initiation, ou (vi) l’opérateur de registre présentait une demande de protection en vertu du code des États-Unis sur la faillite, 11 U.S.C. acticle101 et suivants, ou un code étranger équivalent ou s'il liquidait, dissolvait ou interrompait autrement ses activités ou l’exploitation du TLD.

(e) L’ICANN peut, suite à un préavis de trente (30) jours civils adressé à l’opérateur de registre, résilier ce contrat conformément à l'article 2 de la spécification 7 ou aux articles 2 et 3 de la spécification 11, sous réserve du droit de l’opérateur de registre de contester une telle résiliation tel que cela a été décrit dans la procédure applicable au présent contrat.

(f) L’ICANN peut, suite à un préavis adressé à l’opérateur de registre, résilier ce contrat si (i) l’opérateur de registre employait délibérément un cadre qui a été reconnu coupable de crime ou de délit lié à des activités financières ou de tout autre crime, ou s'il était jugé coupable de fraude ou de manquement à un devoir fiduciaire par un

tribunal de juridiction compétente, ou s'il avait fait l’objet d’une décision judiciaire que l’ICANN considère raisonnablement comme étant substantiellement équivalente à l’un des cas ci-dessus et que ce cadre 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 de l’organe de direction équivalent de l’opérateur de registre était reconnu coupable de crime ou de délit lié à des activités financières ou de tout autre crime, ou était jugé par un tribunal de juridiction compétente

coupable de fraude ou de manquement à un devoir fiduciaire, ou faisait l’objet d’une

décision judiciaire que l’ICANN considère raisonnablement comme étant substantiellement équivalente à l’un des cas ci-dessus et que ce membre n’est pas démis de ses fonctions de membre du Conseil d’administration ou de l’organe de direction équivalent de l’opérateur de registre 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 pourra, en notifiant l’opérateur de registre avec un préavis de trente (30) jours civils, 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.12.

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

(a) L’opérateur de registre peut résilier ce contrat suite à un préavis transmis à l’ICANN si, (i) l’ICANN ne réparait pas tout manquement substantiel et fondamental à ses engagements établis au chapitre 3, dans les trente (30) jours civils suivant le préavis concernant le manquement en question, ce préavis devant inclure tous les détails relatifs au manquement présumé, (ii) un arbitre ou un tribunal de juridiction

compétente avait finalement décidé que l’ICANN se trouve en manquement substantiel et fondamental à ces engagements, et (iii) l’ICANN n’avait pas respecté ladite décision et n’avait pas remédié au manquement en question dans un délai de dix (10) jours civils ou toute autre période définie par l’arbitre ou le tribunal compétent.

(b) L’opérateur de registre peut résilier ce contrat pour toute raison suite à un préavis adressé à l’ICANN cent quatre-vingts (180) jours civils à l’avance.

4.5 Transition du registre après résiliation du contrat. A l’expiration de la durée et conformément à l'article 4.1 ou l'article 4.2 ou de la résiliation de ce 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 désigné par l’ICANN pour le TLD conformément à cet article 4.5, toutes les données (incluant 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 si elle procédera ou pas à la transition de l'opération du TLD à un opérateur de registre successeur, à son entière discrétion et conformément au processus de transition de registre ; à condition, cependant, que (i) 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) lors de la détermination de la transition de l'opération du TLD à un opérateur de registre successeur et (ii) si l'opérateur de registre démontre à l'ICANN de manière raisonnablement satisfaisante (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 affiliés pour leur utilisation exclusive, (B) que l'opérateur de registre ne vend, ne distribue ou ne transfère le contrôle ou l'utilisation d'aucun enregistrement dans le TLD à aucune tierce partie qui ne soit pas affiliée à l'opérateur de registre, et (C) que la transition de l'opération du TLD n'est pas nécessaire pour protéger l'intérêt public, alors l'ICANN peut ne pas procéder à la transition de l'opération du TLD à un opérateur de registre successeur à l'expiration ou à la résiliation de ce contrat sans le consentement de l'opérateur de registre (consentement qui ne sera pas refusé, conditionné ou reporté sans motif valable). Afin d'éviter toute ambiguïté, la phrase précédente n'interdira pas à l'ICANN de déléguer le TLD conformément à un processus de candidature pour la délégation des domaines de premier niveau, soumis à tous les processus et à toutes les procédures d'objection établies par l'ICANN concernant lesdits processus de candidature en vue de protéger les droits de tierces parties. L’opérateur de registre accepte que

l’ICANN puisse apporter les modifications qu’il jugera nécessaires à la base de données IANA pour les enregistrements du DNS et du WHOIS concernant le TLD en cas de transition du TLD conformément au présent article 4.5. De plus, l’ICANN ou l’entité désignée par l’ICANN, conservera et peut renforcer ses droits au titre de l’instrument d’opérations

continues ou de l’instrument alternatif, le cas échéant, indépendamment de la raison de l’expiration ou de la résiliation du présent contrat.

[Texte alternatif pour l'article 4.5 Transition de registre suite à la 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 contrat conformément à l'article 4.1 ou l'article 4.2 ou à la résiliation du présent contrat en vertu de l'article 4.3 ou de 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 auprès de l’opérateur de registre, l’ICANN devra déterminer s’il est préférable ou non de faire passer la gestion du TLD à un opérateur de registre successeur, à son entière discrétion et conformément au processus de transition du registre. Si l’ICANN décide de procéder à la transition et de faire passer la gestion 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 devra fournir à l’ICANN ou à un tel successeur pour le TLD toutes les données relatives aux opérations du TLD et nécessaires à maintenir les opérations et les fonctions de registre pouvant être requises par l’ICANN ou par un tel opérateur de registre successeur, dans la mesure du raisonnable, outre les données déposées conformément à l'article 2.3 de ces 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 retourné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’il jugera nécessaires à la base de données IANA pour les enregistrements du DNS et du WHOIS 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 renforcer ses droits au titre de l’instrument d’opérations continues, indépendamment de la raison de l’expiration ou de la résiliation du présent contrat ».]

4.6 Résultat de la résiliation. A l’expiration de la durée ou à la résiliation de cet accord, les obligations et les droits des parties contractantes de l’accord cesseront, à

condition qu’une telle expiration ou résiliation de ce contrat ne libère pas les parties de toute obligation ou manquement à ce contrat, existant avant l’expiration ou la résiliation incluant mais sans y être limité, toutes les obligations de paiement accumulées et résultant du 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 résiliation du présent accord. . Pour éviter tout doute, 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 ou à la résiliation du présent contrat.

CHAPITRE 5.

RÈGLEMENT DE LITIGES

5.1 Médiation. Si un litige survient dans le cadre du présent contrat ou ayant un rapport avec lui, avant que chaque partie puisse entamer 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ésoudre ce litige par une médiation, conformément aux termes et aux conditions suivants :

(a) l'une des parties devra soumettre un litige à médiation par notification écrite à l'autre partie. La médiation sera menée par un seul médiateur choisi

par les parties. Si les parties ne conviennent pas sur un médiateur dans les quinze (15) jours civils suivant la réception de l'avis de médiation conformément à cet article 5.1, les parties devront sélectionner rapidement une entité de prestation de services de médiation mutuellement acceptable, entité qui devra, dès que possible à la suite de sa sélection, désigner un médiateur, qui sera un avocat agréé ayant des connaissances générales en matière contractuelle, aucun rapport commercial avec aucune des parties et des connaissances générales du système des noms de domaine pour arbitrer sur le différend en particulier. Tout médiateur devra confirmer par écrit qu'il ou elle n'est pas, et ne deviendra pas pendant la durée de la médiation, un employé, un associé, un cadre, un directeur, ou détenteur de titres de l'ICANN ou d'un opérateur de registre. Si le médiateur désigné n'était pas confirmé, 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 ou elle déterminerait, suite à la consultation avec les parties. Les parties discuteront du litige de bonne foi et tenteront, avec l'aide du médiateur, de parvenir à une résolution à l’amiable du litige. La médiation devra être traitée comme la recherche d'un accord, elle sera par conséquent confidentielle et ne pourra pas être utilisée contre aucune des parties dans aucune procédure ultérieure liée au litige, y compris l'arbitrage en vertu de l'article 5.2. Le médiateur ne pourra témoigner en faveur d'aucune des parties dans aucune autre procédure ultérieure liée à ce litige.

(c) Chaque partie supportera ses propres coûts dans la médiation. Les parties assumeront à parts égales les honoraires et les frais du médiateur. Chaque partie traitera l'information reçue de l'autre partie en vertu de la médiation et adéquatement marquée comme confidentielle (comme l'article 7.15 l'exige) comme information confidentielle de ladite partie conformément à l'article 7.15.

(d) Si les parties se sont engagées de bonne foi dans la médiation mais qu'elles n'ont pas pu résoudre le litige pour quelque raison que ce soit, l'une des parties ou le médiateur peuvent annuler 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ésolu le litige pour quelque raison que ce soit quatre-vingt-dix (90) jours civils après la date de la notification selon l'article 5.1(a), la médiation sera automatiquement annulée (à moins qu'elle ne soit étendue suite à un accord entre les parties) et le litige peut donc être réglé au moyen d'un arbitrage, de conformité avec l'article 5.2 ci-après.

5.2 Arbitrage. Les litiges émanant du présent contrat ou ayant un rapport avec celui-ci et n'ayant pas été résolus conformément à l'article 5.1, y compris les demandes d’exécution particulière, seront résolus à travers un arbitrage exécutoire mené conformément aux règles de la Cour internationale d’arbitrage de la Chambre de commerce internationale. 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 demandait des dommages-intérêts punitifs ou exemplaires, ou des sanctions opérationnelles, ou (ii) les parties accordaient par écrit un plus grand nombre d’arbitres, ou (iii) si la dispute découlait 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 face à trois arbitres, chacune des parties ayant choisi un arbitre et les deux arbitres choisis choisissant le troisième arbitre. Afin

d’accélérer l’arbitrage et d’en limiter les coûts, l’arbitre ou les arbitres établiront des limites en matière de pages des dossiers liés à l’arbitrage et, si l’arbitre ou les arbitres

décidaient qu’une audience est nécessaire, la durée de l’audience sera limitée à un (1) jour civil, à condition que dans chaque arbitrage auquel l’ICANN demanderait des

dommages-intérêts punitifs ou exemplaires ou des sanctions opérationnelles, l’audience puisse être prolongée d’un (1) jour civil supplémentaires si cela était convenu par les parties ou ordonné par l’arbitre ou les arbitres par décision indépendante ou à la demande raisonnable de l’une des parties. La partie gagnante de l’arbitrage aura le droit de

récupérer ses frais et les honoraires raisonnables de l'avocat que l’arbitre ou les arbitres devront inclure dans la décision définitive. Au cas où les arbitres détermineraient que l’opérateur de registre a été à plusieurs reprises et délibérément en manquement fondamental ou substantiel aux obligations établies aux chapitres 2 et 6 ou à l'article 5.4 du présent contrat, l’ICANN peut demander à ce que les arbitres désignés décident des dommages-intérêts exemplaires ou punitifs, ou des sanctions opérationnelles (notamment, sans s'y limiter, un ordre temporaire limitant le droit de vente de nouveaux

enregistrements à l’opérateur de registre). Chaque partie traitera l'information reçue de l'autre partie en vertu de la médiation et adéquatement marquée comme confidentielle (comme l'article 7.15 l'exige) comme information confidentielle de ladite partie

conformément à l'article 7.15. Dans tout litige impliquant l’ICANN et concernant le présent contrat, la juridiction, ainsi que le lieu exclusif du déroulement de l’arbitrage d’un tel litige se situeront dans un tribunal du comté de Los Angeles, en Californie (États-Unis) ; toutefois, les parties auront également la possibilité d’appliquer le jugement du tribunal dans toute juridiction compétente.

[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 émanant du présent contrat ou ayant un rapport avec celui-ci et n'ayant pas été résolus conformément à l'article 5.1, y compris les demandes d’exécution particulière, seront résolus à travers un arbitrage exécutoire mené

conformément aux règles de la Cour internationale d’arbitrage de la Chambre de commerce internationale. 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 demandait des dommages-intérêts punitifs ou exemplaires, ou des sanctions opérationnelles, ou (ii) les parties accordaient par écrit un plus grand nombre d’arbitres, ou (iii) si la dispute découlait 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 face à trois arbitres, chacune des parties ayant choisi un arbitre et les deux arbitres choisis choisissant le troisième arbitre. Afin d’accélérer l’arbitrage et d’en limiter les coûts,

l’arbitre ou les arbitres établiront des limites en matière de pages des dossiers liés à

l’arbitrage et, si l’arbitre ou les arbitres décidaient qu’une audience est nécessaire, la durée de l’audience sera limitée à un (1) jour civil, à condition que dans chaque arbitrage auquel l’ICANN demanderait des dommages-intérêts punitifs ou exemplaires ou des sanctions

opérationnelles, l’audience puisse être prolongée d’un (1) jour civil supplémentaires si cela était convenu par les parties ou ordonné par l’arbitre ou les arbitres par décision

indépendante ou à la demande raisonnable de l’une des parties. La partie gagnante de l’arbitrage aura le droit de récupérer ses frais et les honoraires raisonnables de l'avocat que l’arbitre ou les arbitres devront inclure dans la décision définitive. Au cas où les arbitres détermineraient que l’opérateur de registre a été à plusieurs reprises et délibérément en manquement fondamental ou substantiel aux obligations établies aux chapitres 2 et 6 ou à l'article 5.4 du présent contrat, l’ICANN peut demander à ce que les arbitres désignés décident des dommages-intérêts exemplaires ou punitifs, ou des sanctions opérationnelles (notamment, sans s'y limiter, un ordre temporaire limitant le droit de vente de nouveaux enregistrements à l’opérateur de registre). Chaque partie traitera l'information reçue de l'autre partie en vertu de la médiation et adéquatement marquée comme confidentielle (comme l'article 7.15 l'exige) comme information confidentielle de ladite partie conformément à l'article 7.15. Dans tout litige impliquant l’ICANN et concernant le présent contrat, la juridiction ainsi que le lieu exclusif du

déroulement de l’arbitrage d’un tel litige relèveront d’un tribunal situé à 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 le droit d’appliquer le jugement de ce tribunal dans toute juridiction compétente ».]

5.3 Limites de la responsabilité. Le cumul des responsabilités pécuniaires de l’ICANN pour violation du présent accord ne dépassera pas un montant égal aux frais versés au niveau du registre par l’opérateur de registre à l’ICANN au cours de la période précédente de douze mois conformément à cet accord (à l’exception des éventuels frais variables au niveau du registre indiqués dans l’article 6.3, le cas échéant). 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 indiqués dans l'article 6.3), et aux éventuels dommages-intérêts exemplaires et punitifs, 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 ayant un rapport avec lui, ou de l’exécution ou de la

non-exécution des obligations assumées dans ce contrat, à l’exception des dispositions de l'article 5.2. Sauf tel qu’autrement stipulé dans ce contrat, les parties nient toute garantie, formelle ou implicite, par rapport aux services rendus par lesdites parties, leurs fonctionnaires ou agents, ou aux résultats obtenus de leur travail, y compris, sans y être limités, toute garantie implicite de valeur marchande, non-infraction ou aptitude à un emploi particulier.

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 de juridiction compétente une exécution spécifique des conditions du présent contrat (outre toute réparation à laquelle chaque partie auraient droit).

CHAPITRE 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 (dans leur ensemble, les

« frais au niveau du registre ». Les frais de transaction au titre du registre correspondront au nombre de prélèvements annuels d'un enregistrement de nom de domaine initial ou renouvelé (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, chacun considéré comme une « transaction ») au cours du trimestre civil applicable multiplié par USD 0,25 ; à condition, cependant, que les frais de transaction au niveau du registre ne soient pas appliqués jusqu'à ce que 50 000 transactions ou plus n'aient été effectuées dans le TLD pendant tout trimestre civil ou pendant toutes les quatre périodes trimestrielles civiles consécutives dans leur ensemble (le « seuil de transactions ») et qu'ils soient appliqués à chaque transaction réalisée pendant le trimestre où le seuil de transactions ait été atteint, mais qu'ils ne soient pas appliqués pendant tout trimestre où le seuil de transactions n'a pas été atteint. L'obligation de paiement trimestriel des frais fixés au titre du registre pour l'opérateur de registre commencera à la date où le TLD aura été délégué dans le DNS à l'opérateur de registre. Le premier paiement trimestriel des frais 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 où se trouve incluse la date de délégation.

(b) Sous réserve de l'article 6.1(a), l'opérateur de registre paiera les frais au titre du registre sur une base trimestrielle sur un compte désigné par l'ICANN dans les trente (30) jours civils suivant 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 à approuver les 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 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/. Au cas où de telles demandes seraient renvoyées au RSTEP, l’opérateur de registre devra remettre à l’ICANN le tarif facturé du RSTEP dans les quatorze (14) jours civils à compter de la réception d’une copie de la facture du RSTEP par l’ICANN à moins que l’ICANN détermine, à sa seule discrétion, de payer tous les frais facturés pour la révision du RSTEP.

6.3 Frais variables au titre du registre.

(a) Si les bureaux d’enregistrement accrédités par l’ICANN, compte tenu du paiement des deux tiers de tous les frais de niveau du registre (ou de la portion des opérateurs de registre accrédités par l'ICANN étant nécessaires pour approuver les frais variables sous le contrat d'accréditation de bureau d'enregistrement en cours) n'approuvaient pas, selon les termes de leurs contrats d'accréditation de bureau

d'enregistrement avec l’ICANN, les frais d’accréditation variables établis par le Conseil d’administration de l’ICANN pour tout exercice fiscal de l’ICANN, sur livraison d’une

notification de l’ICANN, l’opérateur de registre devra payer à l’ICANN des frais variables au niveau du registre qui seront payés sur une base fiscale trimestrielle et qui s’accumuleront au début de chaque trimestre fiscal de l’exercice fiscal de l’ICANN (les « frais variables au titre du registre »). Les frais seront calculés et facturés par l’ICANN sur une base

trimestrielle et seront payés par l’opérateur de registre dans un délai de soixante (60) jours civils pour le premier trimestre de l’exercice fiscal de l’ICANN et dans un délai de vingt (20) jours civils pour chacun des autres trimestres de l’exercice fiscal de l’ICANN, 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 des parties

contractantes d’un contrat registre-bureau d’enregistrement avec l’opérateur de registre (ce 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 à cet article 6.3), à

condition que les frais soient facturés à tous les bureaux d’enregistrement accrédités par l’ICANN, s’ils étaient facturés. Les frais variables au niveau du registre, si payables à l’ICANN, seront une obligation de l’opérateur de registre et seront dus et payables tel que stipulé dans cet 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. Au cas où l’ICANN percevrait plus tard les frais variables d’accréditation pour lesquels 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 leur contrat

d’accréditation de bureau d’enregistrement avec l’ICANN, les frais d’accréditation variables établis 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 cet 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 peut inclure une composante par bureau

d’enregistrement et une composante transactionnelle. La composante des frais variables au niveau du registre par bureau d’enregistrement 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 selon le 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 les renouvellements associés aux transferts d’un bureau d’enregistrement accrédité par l’ICANN à un autre).

6.4 Frais à payer. L'opérateur de registre paiera à l'ICANN (i) une somme unique correspondant à USD 5000 pour l'accès et l'utilisation du centre d'échange d'information sur les marques tels que ces frais sont décrits dans la spécification 7 (les

« frais d'accès au RPM ») et (ii) USD 0,25 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 ci-joint conformément à la spécification 7) (les « frais d'enregistrement RPM »). Les frais d'accès 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 suivant la date de la facture. L'ICANN facturera trimestriellement les frais d'enregistrement RPM à l'opérateur de registre et lesdits frais seront exigibles suivant la procédure de facturation et de paiement spécifiée à l'article 6.1.

6.5 Ajustements des frais. Nonobstant les limites de frais établies au chapitre 6, à partir de la fin de la première année de ce contrat et à la fin de chaque année suivante pendant toute la durée, les frais alors établis aux articles 6.1 et 6.3 peuvent être ajustés à la discrétion de l’ICANN par 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 ministère du travail des États-Unis, bureau des statistiques de travail ou tout autre index suivant (le « CPI ») pour le mois qui est un (1) mois avant le début de l’année applicable, au dessus (ii) du CPI publié pour le mois qui est un (1) mois avant le début de l’année précédente. S’il y a augmentation, l’ICANN donnera un préavis à l’opérateur de registres précisant le montant de l'ajustement en question. Tout ajustement des frais selon cet article 6.5 prendra effet à partir du premier jour du premier trimestre civil suivant au moins trente (30) jours après que l'ICANN aura notifié l'opérateur de registre d'un tel ajustement des frais.

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

CHAPITRE 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, responsables, employés, et agents (collectivement « les indemnisés ») de et contre toutes les réclamations de tiers, dommages, responsabilités, coûts, et frais, y compris les honoraires et les frais de justice raisonnables, provenant de ou en rapport avec les droits de propriété intellectuelle par rapport au TLD, la délégation du TLD à l’opérateur de registre, le fonctionnement de l’opérateur de registre pour le TLD ou la prestation de services de registre par l’opérateur de registre ; à condition que l’opérateur de registre ne soit pas obligé de dédommager ou de défendre les indemnisés dans la mesure où la réclamation, le dommage, la responsabilité, le coût ou les frais proviennent : (i) à cause d’actions ou d’omissions de l’ICANN, ses sous-traitants, les membres de ses panels ou les

1 Sous réserve d'approbations ultérieures.

évaluateurs spécifiquement liées à et survenant au cours du processus de candidature du registre TLD (hormis les actions ou omissions requises par ou profitant à l’opérateur de registre), ou (ii) à cause d’un manquement de l’ICANN à l’une de ses obligations contenues dans le présent contrat ou d’une mauvaise conduite volontaire de l’ICANN. Le présent

article ne doit pas être considéré comme exigeant de l’opérateur de registre de rembourser ou dédommager de toute autre façon l’ICANN pour les 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 de ces présentes. En outre, le présent article ne s’appliquera pas aux réclamations concernant les honoraires des avocats liés aux les litiges ou à l’arbitrage entre les parties, qui seront régis par le chapitre 5 ou accordés par un tribunal de juridiction compétente ou un arbitre.

[Texte alternatif 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, provenant de ou en rapport avec les droits de propriété intellectuelle relatifs au TLD, la délégation du TLD à l’opérateur de registre, la gestion du registre par l’opérateur de

registre pour le TLD ou la fourniture de services de registre par l’opérateur de registre, sous réserve que l’opérateur de registre ne soit pas tenu de fournir une telle coopération dans la mesure où la réclamation, le dommage, la responsabilité, le coût ou les frais

découlent d’un manquement de l’ICANN à l’une de ses obligations contenues dans le présent contrat ou de toute faute délibérée de la part de l’ICANN. Le présent article ne doit pas être considéré comme exigeant de l’opérateur de registre de rembourser ou dédommager de toute autre façon l’ICANN pour les 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 de ces présentes. En outre, le présent article ne s’appliquera pas aux réclamations concernant les honoraires des avocats en rapport avec les litiges ou

l’arbitrage entre ou parmi les parties, qui seront régis par le chapitre 5 ou accordés par un tribunal de juridiction compétente ou un arbitre » .]

(b) Pour toute demande de dédommagement de l’ICANN par laquelle plusieurs opérateurs de registre (incluant 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 d’indemniser l’ICANN quant à 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 de noms de domaine enregistrés auprès de l’opérateur de registre dans le TLD (lesquels noms enregistrés seront calculés selon le chapitre 6 pour tout trimestre pertinent) par le nombre total des noms de domaine enregistrés dans tous les domaines de premier niveau pour lesquels les opérateurs de registre sont engagés dans les mêmes actes ou omissions donnant 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 à cet article 7.1(b), l’opérateur de registre devra identifier les autres opérateurs de registre engagé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é des autres opérateurs de registre quant à ces actions ou

omissions. Afin d’éviter tout doute, si l’opérateur de registre est impliqué dans les mêmes actions ou omissions ayant donné lieu aux réclamations, mais que ces opérateurs de

registre n’ont pas les mêmes obligations de dédommagement à l’égard de l’ICANN et tel qu’établi à l'article 7.1(a) ci-dessus, le nombre de domaines gérés par cet ou ces opérateur(s) de registre sera néanmoins inclus dans le calcul de la phrase précédente. [Remarque : cet article 7.1(b) n'est pas applicable aux organisations intergouvernementales ou entités gouvernementales].

7.2 Procédures de dédommagement. Si la réclamation de dédommagement d’un tiers au titre de l'article 7.1 ci-dessus est engagée, l’ICANN en notifiera 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 rapidement adressé à l’ICANN, à se charger immédiatement de la

justification et de l'enquête de la réclamation et d’engager et de recourir à des avocats

raisonnablement acceptables pour l’ICANN afin de gérer et de défendre celui-ci, aux frais de l’opérateur de registre uniquement, à condition que dans tous les cas, l’ICANN soit autorisée à contrôler, à ses frais uniquement, les litiges relatifs à la validité ou à l’interprétation des politiques, des statuts ou de la conduite de l’ICANN. L’ICANN devra coopérer, aux frais de l’opérateur de registre, à tous les égards de manière raisonnable avec l’opérateur de registre et ses avocats lors de la vérification, du procès, de la défense de cette réclamation et de tout appel pouvant en découler, et peut, à ses frais uniquement, participer, à travers ses avocats ou autres, à la vérification, au procès et à la défense de la réclamation et de tout appel pouvant en découler. Aucun accord de réclamation qui

impliquerait un recours affectant l’ICANN, autre que le paiement d’une somme d’argent à une hauteur totalement indemnisée par l’opérateur de registre, ne sera enregistré sans le consentement de l’ICANN. Si l’opérateur de registre n’assume pas le contrôle total de la défense d’une réclamation soumise à une telle défense conformément à cet article 7.2, l’ICANN pourra défendre 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 : Cet article 7.2(b) n'est pas applicable aux organisations intergouvernementales ou entités gouvernementales].

7.3 Définition des termes. Pour les besoins du présent contrat, sauf si ces définitions sont amendées conformément à une politique consensuelle à une date ultérieure, auquel cas les définitions suivantes devront être considérées amendées et rétablies dans leur totalité tel que décrit dans la politique consensuelle pertinente, les termes sécurité et stabilité sont définis comme suit :

(a) pour les besoins du présent contrat, un effet sur la « sécurité » signifie

(i) la divulgation, modification, insertion ou destruction non autorisée de données d’enregistrement, ou (ii) l’accès non autorisé à ou la divulgation d’informations ou de ressources sur l’Internet par des systèmes opérant conformément à toutes les normes applicables.

(b) pour les besoins du présent contrat, un effet sur la « stabilité » se réfère à (1) un manque de conformité aux normes pertinentes applicables faisant autorité

et publiées par un organe de normalisation d’Internet bien établi et reconnu tel que le Standards-Track ou les RFC des meilleures pratiques courantes 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 temps de réponse et la cohérence des réponses aux serveurs Internet ou systèmes opérant selon les normes applicables faisant autorité et publiées par un organe de normalisation d’Internet bien reconnu et établi, tel que le Standards-Track ou les RFC des meilleures pratiques courantes 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 de ce contrat seront effectués de manière opportune tout au long de la durée de ce 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 ce établi dans l'article 7.5, aucune des parties ne pourra céder aucun des droits et obligations découlant du présent contrat sauf avec l’autorisation écrite préalable de l’autre partie, qui ne doit pas être refusée sans motif raisonnable. Aux fins de cet article 7.5, un changement direct ou indirect du contrôle de l'opérateur de registre ou tout autre accord de sous-traitance lié à des fonctions critiques (telles qu'elles sont identifiées à l'article 6 de la spécification 10) pour le TLD (un « accord de sous-traitance substantiel ») 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 concernant tous les arrangements substantiels de sous-traitance et tout accord visant à sous-traiter des portions des opérations du TLD (qu'il existe ou pas un arrangement substantiel de sous-traitance) doit stipuler 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 devra également donner à l’ICANN un préavis d’au moins trente (30) jours civils avant l’exécution de toute transaction qui résulterait en un changement direct ou indirect de contrôle de l’opérateur de registre.

(b) Dans les trente (30) jours civils suivant l'une des notifications mentionnées conformément à l'article 7.5(a), l'ICANN peut demander des informations supplémentaires de l'opérateur de registre établissant (i) la conformité avec ce contrat et

(ii) que la partie se chargeant de ce contrôle ou acceptant cette cession ou cet accord de sous-traitance substantiel (dans tous les cas, la « partie contractante ») et la société-mère de la partie contractante répondent à 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 du financement et des capacités opérationnelles et techniques), auquel cas l'opérateur de registre doit fournir l'information requise 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 accord de sous-traitance substantiel

sera aussi soumis à des vérifications d'antécédents de toute partie contractante proposée (ainsi que des affiliés de ladite partie contractante).

(d) Si l’ICANN omet de fournir expressément ou de refuser son

consentement à un changement direct ou indirect de contrôle de l’opérateur de registre ou à un arrangement de sous-traitance substantiel dans les trente (30) jours civils de la

réception de la part de l'ICANN de l'avis de cette transaction (ou, si l’ICANN avait 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 d’un avis écrit d’une telle transaction de la part de l’opérateur de registre), l’ICANN sera considérée comme ayant consenti à une telle transaction.

(e) En rapport avec une telle mission, changement de contrôle ou arrangement de sous-traitance substantiel, l’opérateur de registre doit se conformer au processus de transition du registre.

(f) Malgré ce qui précède,) (i) aucun changement de contrôle accompli ne sera révocable par l'ICANN ; à condition, toutefois, que si l'ICANN détermine raisonnablement de refuser son consentement à ladite transaction, l'ICANN pourra résilier cet accord conformément à l'article 4.3(g) ; (ii) l'ICANN pourra céder ce contrat sans l'autorisation de l'opérateur de registre suite à l'approbation du Conseil d'administration de l'ICANN, ainsi qu'une réorganisation, une reconstitution ou une réincorporation de l'ICANN après la prise en fonction expresse de tel cessionnaire des modalités et des conditions des présentes, (iii) l'opérateur de registre pourra céder le présent contrat sans l'autorisation de l'ICANN directement à une filiale en propriété exclusive de l'opérateur de registre ou, si l'opérateur de registre est une filiale en propriété exclusive, à sa

société-mère ou à une autre filiale en propriété exclusive de sa société-mère dès la prise en fonction expresse, si applicable, de tel cessionnaire ou de sa société-mère des modalités et des conditions des présentes, et (iv) l'ICANN sera considérée comme ayant autorisé toute cession, accord de sous-traitance substantiel ou toute transaction de changement de contrôle où la partie contractante est un opérateur existant d'un domaine de premier niveau générique en vertu d'un contrat de registre entre ladite partie contractante et l'ICANN (à condition que ladite partie contractante agisse de conformité avec les conditions générales d'un tel contrat dans tous ses aspects substantiels), à moins que l'ICANN ne présente à l'opérateur de registre une objection écrite à ladite transaction dans les dix (10) jours civils suivant la réception par l'ICANN de ladite transaction en vertu de cet article 7.5. Nonobstant l'article 7.5(a), au cas où une cession serait faite en vertu des clauses (ii) ou (iii) de cet article 7.5(f), la partie cédante notifiera l'autre partie de cette cession dans les plus brefs délais.

7.6 Amendements et renonciations.

(a) Au cas où le Conseil d'administration de l'ICANN déterminerait qu'un amendement au présent contrat (y compris les spécifications mentionnées dans ces présentes) et à tous les autres contrats de registre entre l'ICANN et les opérateurs de registre applicables (les « contrats de registre applicables » ) est souhaitable (chacun étant

un « amendement spécial » ), l'ICANN pourra approuver un amendement spécial, conformément aux exigences de et aux processus énoncés dans le présent article 7.6 ; à condition qu'un amendement spécial ne soit pas un amendement restreint.

(b) Avant de soumette un amendement spécial à l'approbation de l'opérateur de registre, l’ICANN consultera en toute bonne foi le groupe de travail sur la forme et le fond de l’amendement spécial. La durée d’une telle consultation sera

raisonnablement décidée par l’ICANN selon le contenu de l’amendement spécial. Suite à une telle consultation, l’ICANN pourra proposer l’adoption d’un amendement spécial en publiant le dit amendement sur son site web pendant au moins trente (30) jours civils (la « période de publication ») et en transmettant aux opérateurs de registre concernés un avis sur l'amendement proposé, conformément à l'article 7.9. L’ICANN prendra en

considération les commentaires publics reçus concernant l’amendement spécial au cours de la période de publication (y compris les commentaires soumis par les opérateurs de registre applicables).

(c) Si, dans les cent quatre-vingts (180) jours civils suite à l'expiration de la période de publication (la « période d'approbation »), le Conseil d'administration de l'ICANN approuvait un amendement spécial (qui peut prendre une forme différente de celle soumise aux commentaires du public, mais doit aborder le sujet de l'amendement spécial publié pour commentaires du public, tel que modifié pour refléter et / ou aborder les contributions du groupe de travail et les commentaires du public) l'ICANN donnera avis de tel amendement spécial et le soumettra à l'approbation ou à la désapprobation des opérateurs de registre applicables. Si, pendant la période de soixante (60) jours civils suite la date d'avis de l'ICANN aux opérateurs de registre applicables, tel amendement spécial obtient l'approbation de l'opérateur de registre, et sera réputé approuvé (un « amendement approuvé ») par les opérateurs de registre applicables, et entrera en vigueur et sera considéré comme un amendement au présent contrat sur la date ultérieure de soixante (60) jours à compter de la date dans laquelle l'ICANN aura donné avis de l'approbation de cet amendement approuvé à l'opérateur de registre (la « date d'entrée en vigueur de l'amendement »). Si un amendement spécial ne recevait 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 applicables (un « amendement rejeté »). Un amendement rejeté n'aura aucun effet sur les modalités et les conditions du présent contrat, sauf comme indiqué ci-dessous.

(d) Si le Conseil d'administration de l'ICANN déterminait raisonnablement qu'un amendement rejeté correspond aux catégories é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 un « rapport thématique » (tel que défini dans les statuts de l'ICANN) par l'organisation de soutien aux extensions génériques (la « GNSO ») quant à la substance de tel amendement rejeté. Le processus de développement de politiques mené par la GNSO conformément à ce rapport exigé est désigné ici comme « PDP ». Si tel PDP résulte dans un rapport final soutenu par une majorité qualifiée de la GNSO (telle que définie dans les statuts de l'ICANN) qui soit (i) recommande l'adoption de l'amendement

rejeté comme politique consensuelle, soit (ii) se prononce contre l'adoption de l'amendement rejeté comme une politique consensuelle et, dans le cas de (i) ci-dessus, le Conseil d'administration adopte cette politique de consensus, l'opérateur de registre satisfera ses obligations en vertu de l'article 2.2 du présent contrat. Dans les deux cas, l'ICANN abandonnera l'amendement rejeté et celui-ci n'aura aucun effet sur les modalités et les conditions 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 obligé de lancer un PDP en ce qui concerne un amendement rejeté si, à un moment donné dans la période de douze

(12) mois précédant la présentation de cet amendement rejeté pour l'approbation de l'opérateur de registre en vertu de l'article 7.6(c), l'objet de cet amendement rejeté a fait l'objet d'un PDP conclu ou autrement abandonné ou terminé n’ayant pas entraîné une recommandation de la majorité qualifiée de la GNSO.

(e) Si (a) un amendement rejeté ne correspond pas aux catégories de sujets énoncés à l'article 1.2 de la spécification 1, (b) l'objet d'un amendement rejeté fut, à un moment donné dans la période de douze (12) mois précédant la présentation de cet amendement rejeté pour l'approbation de l'opérateur de registre en vertu de l'article 7.6, l'objet d'un PDP conclu ou autrement abandonné ou terminé qui n'a 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 (A) recommande l'adoption de l'amendement rejeté comme politique consensuelle ou (B) se prononce contre l'adoption de l'amendement rejeté comme politique consensuelle (ou tel PDP a autrement été abandonné ou terminé pour une raison quelconque) ; puis, dans tels cas, le dit amendement rejeté pourra ê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 être dans la portée 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 de l'ICANN) ;

(ii) l'amendement rejeté doit être justifié par un motif considérable et impérieux dans l'intérêt public, doit être enclin à favoriser un tel intérêt, compte tenu de la concurrence des intérêts publics et privés qui sont susceptibles d'être touchés par l'amendement rejeté, et doit être strictement adapté et pas plus large au-delà de ce étant raisonnablement nécessaire pour aborder ce motif considérable et impérieux 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 applicables, et / ou réduit considérablement l'accès du public aux services de noms de domaine, l'amendement rejeté devra être le moyen le moins restrictif raisonnablement disponible pour aborder le motif considérable et impérieux dans l'intérêt public ;

(iv) le Conseil d'administration de l'ICANN devra présenter l’amendement rejeté pour commentaires publics pendant une période minimale de trente (30) jours civils, accompagné d'une explication écrite justifiant sa détermination disant que l'amendement rejeté répond aux exigences énoncées aux alinéas (i) à (iii) ci-dessus ; et

(v) suite à cette période de commentaires publics, le Conseil d'administration de l'ICANN devra (a) procéder à des consultations (ou à la gestion directe de l'ICANN pour mener ces consultations) avec le groupe de travail, les experts en la matière, les membres de la GNSO, les comités consultatifs concernés et d'autres parties prenantes intéressées à l'égard de tel amendement rejeté pour une période minimale de soixante (60) jours civils ; et (b) suite à ces consultations, réapprouver l'amendement rejeté (qui peut être sous une forme différente de celle soumise à l'approbation de l'opérateur de registre, mais doit aborder le sujet de l'amendement rejeté, tel que modifié pour refléter et / ou aborder les contributions du groupe de travail et les commentaires du public) par le vote affirmatif d'au moins les deux tiers des membres du Conseil d'administration de l'ICANN ayant le droit de voter sur cette question, compte tenu de toute politique de l'ICANN concernant cette admissibilité, y compris la politique sur les conflits d'intérêt de l'ICANN (un « amendement du Conseil »).

Un tel amendement du Conseil d'administration, sous réserve de l'article 7.6, sera considéré comme un amendement approuvé, entrera en vigueur et sera considéré comme un amendement au présent contrat à la date correspondant à soixante (60) jours civils après la date dans laquelle l'ICANN ait fourni un avis de l'approbation du dit amendement du conseil à l'opérateur de registre (telle date d'entrée en vigueur sera considérée la date d'entrée en vigueur de l'amendement en vertu de ces présentes). Nonobstant ce qui précède, un amendement du Conseil 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 ne sera pas considéré comme un amendement approuvé si, au cours de la période de trente jours (30) civils suite à l'approbation de l'amendement du Conseil par le Conseil d'administration de l'ICANN , le groupe de travail, au nom des opérateurs de registre applicables, soumet au Conseil d'administration de l'ICANN une alternative à l'amendement du Conseil (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 le motif considérable et impérieux dans l'intérêt public identifié par le Conseil d'administration de l'ICANN comme étant la justification de l'amendement du Conseil ; et

(iii) par rapport à l'amendement du Conseil, résulte : (a) plus strictement adapté pour aborder ce motif considérable et impérieux dans l'intérêt public, et (b) dans la mesure où l'amendement alternatif interdise ou exige des conduites ou des activités, impose des coûts considérables aux opérateurs de registre concernés, ou réduise considérablement l'accès aux services de noms de domaine, soit un moyen moins restrictif pour aborder le motif considérable et impérieux dans l'intérêt public.

Toute proposition d'amendement qui ne réponde pas aux exigences des alinéas (i) à (iii) dans la phrase qui précède ne sera pas considérée comme un amendement alternatif aux termes de ces présentes et par conséquent ne remplacera ni retardera l'entrée en vigueur de l'amendement du Conseil. 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 et sera considéré un amendement approuvé conforme à ces présentes (et entrera en vigueur et sera considéré un amendement au présent contrat à partir de la date correspondant à soixante

(60) jours civils suite à la date dans laquelle l'ICANN aura informé l'approbation de tel amendement alternatif à l'opérateur de registre ; cette date d'entrée en vigueur sera considérée la date d'entrée en vigueur de l'amendement en vertu de ces présentes), à moins qu'au cours de la période de soixante (60) jours civils suivant la date dans laquelle le groupe de travail donne avis au Conseil d'administration de l'ICANN de l'approbation de l'opérateur de registre de tel amendement alternatif (période pendant laquelle l'ICANN consultera avec le groupe de travail concernant l'amendement alternatif), le Conseil d'administration de l'ICANN à travers le vote affirmatif d'un minimum de deux-tiers des membres du Conseil d'administration de l'ICANN admissibles pour voter à ce sujet, compte tenu de toute politique de l'ICANN concernant telle admissibilité, y compris la politique sur les conflits d'intérêt de l'ICANN, rejette l'amendement alternatif. Si (A) l'amendement alternatif n'est pas approuvé par l'opérateur de registre dans le délai de trente (30) jours suite à la présentation du dit amendement alternatif aux opérateurs de registre applicables (et le groupe de travail informera l'ICANN de la date de telle présentation), ou (B) le Conseil d'administration de l'ICANN rejette l'amendement alternatif par vote des deux-tiers, l'amendement du Conseil d'administration (et non l'amendement alternatif) entrera en vigueur et sera considéré comme un amendement du présent contrat à partir de la date correspondant à soixante (60) jours civils suite à la date dans laquelle l'ICANN ait informé l'opérateur de registre (cette date d'entrée en vigueur sera considérée la date d'entrée en vigueur de l'amendement en vertu de ces présentes). Si le Conseil d'administration de l'ICANN rejette un amendement alternatif, le conseil 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 pour rejeter un amendement alternatif aux termes de ces présentes ne libère pas le Conseil 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 le cas où l'opérateur de registre considère qu'un amendement approuvé ne remplit pas les exigences de fond énoncées dans le présent article 7.6 ou a été adopté en violation de l'une quelconque des dispositions de procédure 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 doit être menée par un panel d'arbitrage composé de trois personnes. Toute contestation doit être intentée dans les soixante (60) jours civils suite à la date dans laquelle l'ICANN aura informé l'opérateur de registre de l'amendement approuvé, et l'ICANN pourra regrouper toutes les contestations intentées par les opérateurs de registre (y compris l'opérateur de registre) en une seule procédure.

L'amendement approuvé sera considéré comme n‘ayant pas amendé le présent contrat pendant la durée du processus de règlement de litiges.

(h) L'opérateur de registre pourra demander par écrit à l'ICANN une exemption de l'amendement approuvé (chaque demande telle 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 suite à la date dans laquelle l'ICANN ait avisé l'opérateur de registre de tel amendement approuvé. Toute demande d’exemption décrira le fondement d’une telle demande et fournira une justification détaillée de l’exemption de l’amendement approuvé. Une demande d’exemption pourra aussi inclure une description détaillée et la justification d’alternatives ou de variations de l’amendement approuvé, proposées par l’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 condition financière ou les résultats des activités de l’opérateur de registre. Xxxxx demande d’exemption ne sera octroyée si l’ICANN décide, à sa discrétion raisonnable, que l’octroi d’une telle exemption serait substantiellement nuisible aux titulaires de nom de domaine ou résulterait en un déni de bénéfice direct pour

les titulaires de nom 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 sous condition ou consister en alternatives ou en une variation de l’amendement approuvé) ou refusera l’exemption par écrit. Pendant cette période l’amendement approuvé ne s’appliquera pas au présent accord. Si la demande d'exemption est approuvée par l'ICANN, l'amendement approuvé n'amendera pas le présent accord, à condition que toutes les conditions, alternatives ou variations de l'amendement approuvé exigés par l'ICANN soient en vigueur et, dans la mesure du possible, amendent le présent accord à compter de la date d'entrée en vigueur de l'amendement. Si 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, tel amendement approuvé sera considéré immédiatement en vigueur à la date du refus), à condition que l'opérateur de registre puisse, dans les trente (30) jours civils suite à la

réception de la décision de l’ICANN, faire appel à la décision de l’ICANN de refuser la demande d’exemption, conformément aux procédures de règlement de litiges décrites dans le chapitre 5. L'amendement approuvé sera considéré comme n‘ayant pas amendé le présent contrat pendant la durée du processus de règlement de litiges. Pour éviter tout doute, seules les demandes d’exemption soumises par l’opérateur de registre et approuvées par l’ICANN en vertu de cet article 7.6(c), étant accordé que l'ICANN poursuive la médiation conformément à l'article 5.1 ou par le biais d’une décision d’arbitrage

conformément à l’article 5.2, exempteront l’opérateur de registre de l’application de

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

(i) A l’exception des dispositions prévues dans le présent article 7.6, dans l'article 7.7 et autrement établi dans ce contrat et dans les spécifications de ce 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 mention dans ces articles 7.6 ou 7.7 n’empêchera l’ICANN ni 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 est présentée par un écrit signé par la partie qui renonce à respecter cette disposition. Aucune renonciation à l’une des dispositions du présent contrat ou un manquement à appliquer l’une de ces dispositions ne sera réputé être ou ne constituera une renonciation aux autres dispositions et elle ne constituera pas une renonciation continue sauf stipulation formelle contraire. Pour éviter tout doute, rien dans ces articles 7.6 ou 7.7 ne doit être considéré comme limitant l’obligation de l’opérateur de registre de se conformer à l'article 2.2.

(j) Pour les besoins du présent contrat, les termes suivants auront les significations suivantes :

(i) « Opérateurs de registre applicables » signifie, collectivement, les opérateurs de registre des domaines de premier niveau, parties d’un accord de registre qui comprend une disposition similaire à cet article 7.6, y compris l’opérateur de registre.

(ii) « Approbation d’opérateur de registre » signifie la réception de chacun des documents suivants : (A) l’approbation affirmative des opérateurs de registre applicables dont les paiements à l’ICANN ont représenté les deux-tiers du montant total des frais (convertis en dollars US, le cas échéant, au taux de change publié le jour avant dans l'édition américaine du Wall Street Journal pour la date où le calcul est effectué par l'ICANN) payés à l’ICANN par tous les opérateurs de registre applicables durant l’année civile immédiatement précédente conformément aux contrats de registre applicables, et (B) l’approbation affirmative d’une majorité des opérateurs de registre applicables au moment de l’obtention d’une telle approbation. Pour éviter tout doute, concernant la clause (B), chaque opérateur de registre applicable disposera d’un vote pour chaque domaine de premier niveau exploité par cet opérateur de registre selon un contrat de registre applicable.

(iii) « Amendement limité » signifie ce qui suit : (i) un amendement de la spécification 1, (ii) sauf dans la mesure traitée dans l'article 2.10 du présent contrat, 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 dans le premier paragraphe de l'article 2.1 de la spécification 6, ou

(D) un amendement à la longueur de la durée.

(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 articulé qui est dans la mission de l'ICANN et compatible avec une application équilibrée des valeurs fondamentales de l'ICANN telles que définies dans les statuts de l'ICANN.

(v) « Groupe de travail » signifie des représentants des opérateurs de registre applicables et d’autres membres de la communauté nommés par le groupe des représentants des opérateurs de registre, de temps à autre, pour servir en tant que groupe de travail pour la consultation relative aux amendements des contrats des opérateurs de registre applicables (à l’exception des amendements bilatéraux visés à l'article 7.6(i)).

(k) Nonobstant toute disposition contraire dans le 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 prestation des services de l'opérateur de registre, l'ICANN remettra la date d'entrée en vigueur de l'amendement approuvé à l'égard de l'opérateur de registre de cent quatre-vingts (180) jours civils , et (ii) aucun amendement approuvé conformément à l'article 7.6 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 (« PDG ») ou le président du groupe des représentants des opérateurs de registre (« président ») désirent discuter de toute révision au présent contrat, le PDG ou le président, selon le cas, avisera par écrit l'autre personne, qui exposera de façon suffisamment détaillée les modifications proposées au présent contrat (un « avis de négociation »). Nonobstant ce qui précède, ni le PDG ni le président pourront (i) proposer des modifications au présent contrat qui modifient en rien la politique consensuelle en vigueur, (ii) proposer des modifications au présent contrat conformément au présent article 7.7 avant le 30 Juin 2014 ou ce jour même, ou ( iii) proposer des modifications 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 dans l'article 7.6) procéderont à des négociations de bonne foi concernant la forme et le contenu des modifications proposées au présent contrat, qui doivent être sous la forme d'un amendement proposé au présent contrat (les « modifications proposées » ), pour une période minimale de

quatre-vingt-dix (90) jours civils (sauf si une résolution est atteinte avant ce délai) et tenter

de parvenir à un accord mutuellement acceptable concernant les modifications proposées (la « période de discussion »).

(c) Si, suite à la période de discussion, un accord est atteint sur les modifications proposées, l'ICANN publiera les modifications proposées mutuellement convenues sur son site Web pour 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 applicables conformément à l'article 7.9. L’ICANN et le groupe de travail prendront en considération les commentaires publics reçus concernant les révisions proposées au cours de la période de publication (y compris les commentaires soumis par les opérateurs de registre applicables). Suite à la période de publication, les modifications proposées seront soumises à l'approbation de l'opérateur de registre (tel que défini dans l'article 7.6) et à l'approbation du Conseil d'administration de l'ICANN. Si ces approbations sont obtenues, les modifications proposées seront considérées un amendement approuvé (tel que défini dans l'article 7.6) par les opérateurs de registre applicables et l'ICANN, et entreront en vigueur et seront considérées des amendements au présent contrat après soixante (60) jours civils à compter de la date dans laquelle l'ICANN aura informé l'opérateur de registre.

(d) Si, suite à la période de discussion, un accord n'est pas conclu entre l'ICANN et le groupe de travail sur les révisions proposées, soit le PDG ou le président pourront aviser l'autre partie par écrit ( « avis de médiation » ) de la demande à chaque partie de tenter de résoudre les désaccords liés aux modifications proposées à travers une médiation impartiale et de facilitation (non d'évaluation), conformément aux modalités et aux conditions énoncées ci-dessous. Si un avis de médiation était 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 modifications proposées et un document 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 conviennent pas sur un médiateur dans les quinze

(15) jours civils suivant 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 une entité de prestation de services de médiation mutuellement acceptable, entité qui devra, dès que possible à la suite de sa sélection, désigner un médiateur, qui sera un avocat agréé ayant des connaissances générales en matière contractuelle, n'ayant pas des relations commerciales avec aucune des parties et possédant des connaissances générales du système des noms de domaine pour arbitrer sur le différend en particulier. Tout médiateur devra confirmer par écrit qu'il ou elle n'est pas, et ne deviendra pas pendant la durée de la médiation, un employé, un associé, un cadre, un directeur, ou détenteur de titres de l'ICANN ou d'un opérateur de registre applicable. Si le médiateur désigné n'était pas confirmé, 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 de la médiation de facilitation qu'il décide, suite à sa consultation avec les parties. Les parties discuteront du litige de bonne foi et tenteront, avec l'aide du médiateur, de parvenir à une résolution à l’amiable du litige.

(iii) Chaque partie supportera ses propres coûts dans la médiation. Les parties assumeront à parts égales les honoraires et les frais du médiateur.

(iv) Si un accord est conclu au cours de la médiation, l'ICANN devra publier les modifications proposées mutuellement convenues sur son site web pendant la période de publication et en informera tous les opérateurs de registre applicables conformément à l'article 7.9. L’ICANN et le groupe de travail prendront en considération les commentaires publics reçus sur les révisions proposées ayant été accordées au cours de la période de publication (y compris les commentaires soumis par les opérateurs de registre applicables). Suite à la période de publication, les modifications 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 modifications proposées seront considérées un amendement approuvé (tel que défini dans l'article 7.6) par les opérateurs de registre applicables et l'ICANN, et entreront en vigueur et seront considérées des amendements au présent contrat après soixante (60) jours civils à compter de la date dans laquelle l'ICANN aura informé l'opérateur de registre.

(v) Si les parties ne parviennent pas à régler le litige pour une raison quelconque avant la date correspondant à quatre-vingt-dix (90) jours civils suivant la réception par le PDG ou le président, selon le cas, de l'avis de médiation, la médiation prendra fin automatiquement (sauf prorogation par accord des parties). Le médiateur remettra aux parties une définition des questions qui pourraient être considérées dans un arbitrage futur, s'il était mené. 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 modifications proposées, soit le PDG ou le président peuvent donner à l'autre partie un avis écrit (un « avis d'arbitrage » ), exigeant à l'ICANN et aux opérateurs de registre applicables de résoudre le litige à travers un arbitrage exécutoire conformément aux dispositions d'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 modifications proposées (soit celles de l'ICANN, soit celles du groupe de travail, soit les deux) devront être publiées pour les

commentaires du public 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 du public concernant les modifications proposées soumises au cours de la période de publication (y compris les commentaires soumis par les opérateurs de registre applicables), ainsi que les informations concernant tels commentaires et présenteront leur avis à un panel de trois (3) arbitres. Chaque partie pourra changer ses modifications 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 commentaires publics, et l'ICANN pourra regrouper toutes les contestations intentées par les opérateurs de registre (y compris l'opérateur de registre) en une seule procédure. Sauf ce établi dans le présent article 7.7, l'arbitrage sera effectué en conformité avec à l'article 5.2.

(ii) Aucun litige concernant les modifications proposées ne pourra être soumis à l'arbitrage dans la mesure où l'objet des modifications proposées (i) soit lié à la politique de consensus, (ii) corresponde aux catégories é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 modifications proposées visent à mettre en place un mécanisme de protection de droits (RPM) qui n'est pas visé par l'article 2.8 et la spécification 7); la pièce A et les spécifications 1, 4, 6, 10 et 11.

(iii) Le médiateur informera le panel d'arbitres des propositions concernant les modifications proposées respectives de l'ICANN et du groupe de travail.

(iv) Aucun amendement au présent contrat relatif aux modifications proposées ne peut être soumis à l'arbitrage, soit par le groupe de travail, soit par l'ICANN, à moins que, dans le cas du groupe de travail, l'amendement proposé ait reçu l'approbation de l'opérateur de registre et, dans le cas de l'ICANN, l'amendement proposé ait été approuvé par le Conseil d'administration de l'ICANN.

(v) Pour que le panel d'arbitres approuve les amendements proposés aux modifications proposées soit par l'ICANN, soit par le groupe de travail, le panel d'arbitres devra conclure que tel amendement proposé se conforme à une application équilibrée des valeurs fondamentales de l'ICANN (telles que décrites dans les statuts de l'ICANN) et raisonnable en ce qui concerne l'équilibre entre les coûts et les bénéfices pour les intérêts commerciaux des opérateurs de registre applicables et l'ICANN (le cas échéant), et l'intérêt public poursuivi par les modifications proposées tel que l'indique le dit amendement. Si le panel d'arbitres conclut que l'amendement

proposé soit par l'ICANN, soit par le groupe de travail concernant les modifications proposées répond à la norme qui précède, un tel amendement entrera en vigueur et sera considéré un amendement au présent contrat après soixante (60) jours civils de préavis de l'ICANN à l'opérateur de registre et considéré un amendement approuvé en vertu des présentes.

(f) En ce qui concerne un amendement approuvé relatif à un amendement proposé par l'ICANN, le bureau d’enregistrement pourra demander par écrit à l'ICANN une exemption de cet amendement, conformément aux dispositions de l'article 7.6.

(g) Nonobstant toute disposition contraire dans le 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 prestation des services de registre, l'ICANN remettra la date d'entrée en vigueur de l'amendement approuvé à l'égard du bureau d’enregistrement de cent quatre-vingts (180) jours civils , et

(b) aucun amendement approuvé conformément à l'article 7.7 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.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 faites selon les articles

7.6 et 7.7, toutes les notifications remises dans le cadre du présent contrat, ou en rapport avec ce dernier, seront faites soit (i) par écrit, envoyées à l’adresse de la partie concernée comme indiqué ci-dessous, soit (ii) par télécopie ou courrier électronique, comme spécifié ci-dessous, sauf si cette partie a signalé un changement d’adresse postale ou électronique, ou de numéro de télécopie, tel qu’indiqué dans ce contrat. Toutes les notifications faites au titre des articles 7.6 et 7.7 doivent être effectuées en affichant les informations en question sur le site web de l’ICANN en plus de la transmission des dites informations par courrier électronique à l’opérateur de registre. Toute modification apportée à ses informations de contact sera informée par la partie concernée dans un délai de trente (30) jours civils. Sauf pour les notifications faites au titre 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 ou télécopie, sur confirmation de la réception par le télécopieur ou le serveur de messagerie, à condition que cet envoi par

télécopie ou par xxxxxxxx soit suivi par l’envoi d’une copie par poste dans les deux (3) jours civils. Toute notification requise par les articles 7.6 et 7.7 sera réputée avoir été transmise lorsqu’elle est publiée sur le site web de l’ICANN ou à confirmation de réception par le serveur de messagerie. Au cas où d’autres moyens de notification seraient utilisés, comme une notification via un site Internet sécurisé, les parties travailleront ensemble afin de mettre en œuvre ces moyens de notification dans le cadre de ce contrat.

Pour l’ICANN, les courriers sont envoyés à :

Internet Corporation for Assigned Names and Numbers 00000 Xxxxxxxxxx Xxxxx, Xxxxx 000

Xxx Xxxxxxx, XX 00000-0000 XXX

Téléphone : x0-000-000-0000 Télécopie : 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‘il est parfois précisé.)

Pour l'opérateur de registre, les courriers sont envoyés à : [_ _] [_ _ ] [ ]

Téléphone :

Avec une copie obligatoire pour :

E-mail : (tel qu‘il est parfois précisé.)

7.10 Intégralité du contrat. Ce contrat (y compris les spécifications et les documents intégrés en référence aux emplacements URL qui forment une partie de

celui-ci) constitue l’intégralité de l’accord des parties, en rapport avec le fonctionnement du TLD et remplace tous les contrats, arrangements, négociations et discussion conclus préalablement, à l’écrit ou à l’oral, entre les parties sur ce sujet.

7.11 Prédominance de la version anglaise. En dépit de la traduction du présent contrat et/ou des spécifications susceptibles d’être fournies à l’opérateur de registre, la version anglaise du présent contrat et de toutes les spécifications référencé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 faites dans le cadre du présent contrat le seront en anglais.

7.12 Droits de propriété. Rien dans la teneur du présent contrat ne peut être interprété comme (a) établissant ou accordant à l’opérateur de registre tout droit de propriété ou intérêt relatif au TLD ou aux lettres, mots, symboles ou autres caractères composant la chaîne du TLD, ou (b) portant atteinte à tous les droits de propriété intellectuelle ou de propriété existants de l'opérateur de registre.

7.13 Gravité ; conflits avec les lois. Le présent contrat doit être considéré divisible : l’invalidité ou la non exigibilité d’une condition ou d’une disposition du présent contrat n’a pas d’incidence sur la validité et l’exigibilité du reste du présent contrat ou de toute autre condition y comprise et le présent contrat restera en pleine vigueur. S’il est établi que l’une quelconque des dispositions du présent contrat est invalide ou non exigible, les parties négocieront de bonne foi pour modifier ce contrat de sorte à satisfaire l’intention originelle des parties autant que possible. L'ICANN et le groupe de travail vont mutuellement coopérer pour élaborer une procédure de l'ICANN pour la révision et la

considération par l'ICANN de prétendus conflits entre les lois applicables et les dispositions non liées au WHOIS concernant ce contrat. Jusqu'à ce que cette procédure soit développée et mise en œuvre par l'ICANN, l'ICANN examinera et considérera tout conflit présumé entre les lois applicables et les dispositions non liées au WHOIS de ce contrat 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 Ordre émis par un tribunal. L’ICANN respectera tout ordre émis par un tribunal de juridiction compétente, y compris tous ordres émis par toute juridiction où le consentement ou la non objection du gouvernement serait une condition pour la délégation du TLD. Nonobstant toute autre disposition du présent contrat, la mise en œuvre par l’ICANN d’un tel ordre ne constituera pas un manquement aux dispositions du présent contrat.

7.15 Confidentialité

(a) Sous réserve de l' article 7.15(c), pendant le délai établi et pour une période de trois (3) ans par la suite, chaque partie devra amener ses dirigeants, administrateurs, employés et agents et ceux de ses affiliés à maintenir confidentielle et à ne pas publier ou divulguer à des tiers, directement ou indirectement, toute information étant, ou toute information que la partie divulgatrice a signalé comme étant, 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, des « 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'appliquent pas à toute information confidentielle qui (i) est, ou deviendra du domaine public par l'usage public, publication, connaissances générales ou similaire sans aucune faute de la partie destinataire en violation du présent contrat, (ii) peut être démontrée par des documents ou autre preuve compétente pour avoir été en possession de la partie destinataire avant la divulgation par la partie qui les communique sans aucune obligation de confidentialité à l'égard de cette information, (iii) est ensuite reçue par la partie destinataire d'un tiers qui n'est pas lié par une obligation de confidentialité à l'égard de cette information, (iv) a été publiée par un tiers ou entre dans le domaine public sans faute de la partie destinataire, ou (v) qu'il peut être démontré par des documents ou d'autres preuves compétentes pour avoir été développée 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 renseignements confidentiels dans la mesure où une telle divulgation est (i) faite en réponse à un ordre 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 ait auparavant donné un avis à la partie divulgatrice ainsi qu'une possibilité raisonnable d'annuler un tel ordre ou d'obtenir un ordre de protection ou un ordre de traitement confidentiel exigeant que l'information confidentielle faisant l'objet

d'un tel ordre ou toute autre loi applicable faisant l'objet de la confiance de ce tribunal ou d'un autre tiers bénéficiaire, à moins que la partie destinataire ne soit pas autorisée à fournir ces avis en vertu d'un tel ordre ou d'une loi applicable, ou (ii) faite par la partie destinataire ou une de ses filiales à ses ou leurs avocats, auditeurs, conseillers, consultants, entrepreneurs ou autres tierces parties pour l'utilisation par toute personne ou entité tel que cela pourrait être nécessaire ou utile dans le cadre de l'exécution des activités en vertu du présent accord, à condition que ladite tierce partie soit liée par des obligations de confidentialité au moins aussi sévères que celles figurant dans le présent document, que ce soit par écrit ou de par des normes de responsabilité professionnelle.

[Remarque : l'article suivant n'est applicable qu'aux organisations intergouvernementales ou entités gouvernementales].

7.16 Disposition spéciale relative aux organisations intergouvernementales ou aux organismes gouvernementaux..

(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 (un tel droit international public et de tels traités étant ci-après collectivement désignés comme 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 associées à celui-ci, ou toute décision ou politique de l’ICANN mentionnées dans le présent contrat, y compris, sans s’y

limiter, les politiques provisoires ou de consensus (de telles dispositions, spécifications et politiques ci-après collectivement désignées comme « 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 notifier l’ICANN de façon détaillée (ci-après, une « notification

») 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 toute exigence d l’ICANN, l’opérateur de registre doit faire parvenir à l’ICANN une notification 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 devront tenter de résoudre le conflit potentiel par un engagement de coopération, 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 toute exigence de l’ICANN. Si, suite à cette médiation, l’opérateur de registre

établit que le conflit potentiel constitue en fait un conflit entre toute 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 de 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), excepté si l’ICANN établit, de façon raisonnable et objective, que le manquement de l’opérateur de registre à se conformer à ladite 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 de la notification de telles Conclusions de l’ICANN par l’opérateur de registre, celui-ci devra disposer d’une période de quatre-vingt-dix (90) jours pour résoudre un tel conflit avec la législation

applicable. Si le conflit avec la Législation applicable n’est pas résolu à l’entière satisfaction de l’ICANN au cours de cette période, l’opérateur de registre aura la possibilité de soumettre la question à un arbitrage exécutoire comme défini au sous-article (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-article (d) ci-dessous, l’ICANN pourra, après notification à 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 la question à 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é obtenues 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é obtenues 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’intermédiaire auquel les parties auront recours de façon préalable à l’arbitrage, le cas échéant, établissent que les conclusions de l’ICANN ont été obtenues de façon raisonnable et objective, alors, en notifiant l’opérateur de registre, l’ICANN pourra résilier le présent contrat, la résiliation prenant effet immédiatement.

(e) En vertu de ces 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 ni ne viole aucune législation applicable.

(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é l’opérateur de registre au préalable, 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 provisoire, jusqu’à la date survenant la première entre : la date de conclusion de la procédure d’arbitrage mentionnée à l'article 7.16(d) ci-dessus et la date de résolution complète du conflit avec la législation applicable. Si l’opérateur de registre est en désaccord avec les mesures

techniques prises par l’ICANN, il pourra soumettre la question à un arbitrage exécutoire conformément aux dispositions de l'article 5.2 ci-dessus, sachant 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 en conséquence de telles mesures. En outre, si l’ICANN prend de telles mesures, l’ICANN conservera et pourra appliquer ses droits en vertu de l’instrument assurant la

continuité des opérations et de l’instrument alternatif, le cas échéant.

* * * * *

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

SOCIETE POUR L'ATTRIBUTION DES NOMS DE DOMAINE ET DES NUMEROS SUR INTERNET

Par :

__ _ [_ ]

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

[Opérateur de registre]

Par :

__ _ [_ _]

[_ _] Date :

PIÈCE A

Services approuvés

Le guide de candidature gTLD de l'ICANN (situé à xxxx://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 effective du contrat, et l'opérateur de registre peut fournir les services suivants :

SPÉCIFICATION 1

SPÉCIFICATION DES POLITIQUES CONSENSUELLES ET DES POLITIQUES

PROVISOIRES

1. Politiques consensuelles.

1.1. Les « politiques consensuelles » sont les politiques établies (1) conformément à la procédure formulée dans les statuts de l'ICANN et à la procédure légale, et (2) relatives aux sujets énoncés dans l'article 1.2 de cette spécification Le processus et la procédure d'élaboration des politiques consensuelles établis dans les statuts de l'ICANN peuvent être révisés de temps à autre conformément à la procédure définie dans le présent document.

1.2. Les politiques consensuelles et les procédures régissant leur élaboration seront conçues pour produire, dans la mesure du possible, un consensus des acteurs de l'Internet, notamment des opérateurs de gTLD. Les politiques consensuelles concerneront l'un ou plusieurs des sujets suivants :

1.2.1 les problèmes pour lesquels 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 de performance relatives à 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 consensuelles relatives aux opérations de registre ;

1.2.5 le règlement des différends 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 les revendeurs des bureaux d'enregistrement, les règlementations et restrictions par rapport aux opérations de registre et l’utilisation des données des opérateurs de registre et des bureaux d'enregistrement au cas où un opérateur de registre et un bureau d'enregistrement ou un revendeur des bureaux d'enregistrement seraient affiliés.

1.3. Ces catégories de problèmes mentionnées dans le présent article 1.2 de cette 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 des noms de domaine ou la spéculation sur les noms de domaine par les opérateurs de registre ou les bureaux d'enregistrement ;

1.3.3 la réservation des noms enregistrés dans le TLD qui peuvent ne pas être enregistrés initialement ou qui peuvent ne pas être renouvelés en raison de motifs raisonnablement liés (a) à la nécessité d’éviter toute confusion ou erreur des utilisateurs, (b) à la propriété intellectuelle ou (c) à la gestion technique du DNS ou de l'Internet (par exemple, établissement de réservations de noms à partir de 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 à l'interruption 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 interruption.

1.4. Outre les autres limitations relatives aux politiques consensuelles, ces politiques respecteront également les impératifs suivants ; à savoir, elles ne pourront pas :

1.4.1 prescrire ou limiter le prix des services de registre ;

1.4.2 modifier les conditions ou modalités relatives au renouvellement ou à la résiliation du contrat de registre ;

1.4.3 modifier les limitations relatives aux politiques provisoires (définies ci-dessous) ou aux politiques consensuelles ;

1.4.4 modifier les dispositions du contrat de registre concernant les frais acquittés par l'opérateur de registre auprès de l’ICANN ; ou

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

2. Politiques provisoires. 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 sur une base 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 telles modifications ou de tels amendements sont justifiés, et que l'établissement provisoire immédiat d'une spécification ou d'une politique à ce sujet est nécessaire pour maintenir la stabilité ou la sécurité des services de registre ou du DNS (« Politiques

provisoires »).

2.1. Cette proposition de spécification ou de politique devra être le mieux adaptée possible pour atteindre ces objectifs. Lors de l'établissement de toute politique provisoire, le Conseil d'administration définira la période pour laquelle cette politique provisoire est adoptée et mettra immédiatement en œuvre le processus de développement de politiques consensuelles défini dans les statuts de l'ICANN.

2.1.1 L'ICANN émettra également une déclaration consultative contenant une explication détaillée de ses motifs pour adopter la politique provisoire et des raisons pour lesquelles le conseil d'administration pense que cette politique provisoire doit recevoir le soutien consensuel des acteurs d'Internet.

2.1.2 Si la période pour laquelle la politique provisoire est adoptée excède quatre-vingt-dix (90) jours civils, le Conseil d'administration réitérera son adoption temporaire tous les quatre-vingt-dix (90) jours civils durant une période totale ne pouvant pas dépasser un (1) an, afin de maintenir en vigueur cette politique provisoire jusqu'à ce délai après lequel elle deviendra une politique consensuelle. Si la période d'un

(1) an expirait ou, si durant cette période d'un (1) an, la politique provisoire ne devenait pas une politique consensuelle et n'était pas réaffirmée par le Conseil d'administration, l'opérateur de registre ne sera plus tenu de respecter ni de mettre en œuvre cette politique provisoire.

3. Avis et litiges. L'opérateur de registre se verra accorder un délai raisonnable suite à l'avis d'établissement d'une politique consensuelle ou d'une politique provisoire pour se conformer à cette spécification ou cette politique, en tenant compte de l'urgence éventuellement associée. En cas d'incompatibilité entre des services de registre et des politiques consensuelles ou une politique provisoire, les politiques consensuelles ou la politique provisoire prévaudront, mais uniquement en ce qui concerne le point en conflit.

SPÉCIFICATION 2 CONDITIONS DU DÉPÔT DE DONNÉES

L'opérateur de registre engagera une entité indépendante pour agir en tant que dépositaire

légal de données (le « dépositaire légal ») pour la fourniture de services de dépôt 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 de dépôt de données entre l’opérateur de registre et le dépositaire légal, en vertu duquel l’ICANN peut être nommée tiers bénéficiaire. Outre les exigences suivantes, le contrat de dépôt de données peut contenir d'autres dispositions qui ne sont pas contradictoires ni destinées à subvertir les conditions obligatoires définies ci-dessous.

PARTIE A – SPÉCIFICATIONS TECHNIQUES

1. Dépôts. Il existe deux types de dépôts : complets et différentiels. Quelle que soit la nature du dépôt, les objets de registres à prendre en compte pour le dépôt de données sont les objets 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 à 00h00 UTC (temps universel coordonné) le jour que ledit dépôt complet est soumis au dépositaire légal.

1.2. Les « dépôts différentiels » signifient les 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 précédent, 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, à 00h00 UTC tous les jours, sauf le dimanche. Les dépôts différentiels doivent inclure les enregistrements de dépôt complets, comme spécifié ci-dessous, n'ayant pas été inclus ou modifiés depuis le dernier dépôt complet ou différentiel (par exemple, les noms de domaine ajoutés ou modifiés).

2. Planification des dépôts. L'opérateur de registre est tenu d'envoyer 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é au dépositaire légal à 23h59 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é au dépositaire légal à 23h59 UTC.

3. Spécification du format des dépôts.

3.1. Format des dépôts. Les objets de registre, 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

draft-xxxxx-xxxxxxx-registry-data-escrow, voir la partie A, article 9, référence 1 de cette spécification et draft-arias-noguchi-dnrd-objects-mapping, voir la partie A, article 9, référence 2 de cette spécification (collectivement, la « spécification DNDE »). La spécification DNDE décrit certains éléments comme étant facultatifs ; l'opérateur de registre inclura ces éléments dans les dépôts s'ils sont disponibles. Si ce n'est pas déjà une RFC, l'opérateur de registre utilisera la version la plus récente de la spécification DNDE disponible à la date d'entrée en vigueur. L'opérateur de registre peut à son choix utiliser des versions plus récentes de la spécification DNDE après la date d'entrée en vigueur. Lorsque la spécification DNDE est publiée sous forme de norme RFC, l'opérateur de registre mettra en œuvre cette version de la spécification DNDE, au plus tard après cent quatre-vingts (180) jours civils. 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 cette 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 accorder des spécifications du dépôt de données de ce type de nouveaux objets.

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 pour compression et 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 signalés comme étant dépréciés 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 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 nommé comme le fichier de contention tel que spécifié dans l'article 5, mais avec une extension xml.

(2) Les fichiers de zone sont regroupés dans des fichiers distribués nommés comme à (1), mais avec l'extension tar.

(3) Un message OpenPGP comprimé et encodé est créé en utilisant le fichier avec extension tar 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 du dépositaire légal. 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 etCAST5, conformément à la norme RFC 4880.

(4) Le fichier peut être divisé en plusieurs parties si, une fois compressé et chiffré, sa taille était supérieure à la limite convenue avec le dépositaire légal. Dans cet article, chaque partie d’un fichier divisé, ou l’intégralité du fichier s’il n’est pas divisé, est appelée 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 au dépositaire légal via des mécanismes électroniques sécurisés, tels que SFTP, SCP, HTTPS, etc. comme convenu entre le dépositaire légal 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) Le dépositaire légal valide ensuite chaque fichier de données transféré (traité), conformément à la procédure décrite dans la partie A, article 8 de cette 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 de IDN-TLD, le format compatible ASCII (libellé ASCII) doit être utilisé ;

5.2. {AAAA-MM-JJ} est remplacé par la date correspondant à l’heure utilisée comme limite pour les transactions ; par exemple, pour le dépôt complet correspondant à l’heure 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 aux données d'enregistrement en masse, comme indiqué à l’article 3 de la spécification 4 ;

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 des clés publiques. L'opérateur de registre et le dépositaire légal doivent s'échanger leur clé publique 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 un message de réponse ; 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 message via le serveur de messagerie exploité par la partie qui a effectué l'envoi. Le dépositaire légal, 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 au dépositaire légal et à l’ICANN (en utilisant l'API décrit à

draft-lozano-icann-registry-interfaces, voir partie A, article 9, référence 5 de cette spécification (la spécification d'interface)) une déclaration écrite (é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. L'opérateur de registres 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 cette spécification.

Si ce n'est pas déjà une RFC, l'opérateur de registre utilisera la version la plus récente de la spécification de l'interface à la date d'entrée en vigueur. L'opérateur de registre peut à son choix utiliser les versions plus récentes de la spécification d'interface après la date d'entrée en vigueur. Une fois que la spécification de

l'interface est publiée comme RFC, l'opérateur de registre mettra en œuvre cette version de la spécification de 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) Si la partie A, article 9, référence 1 de la présente spécification comporte une procédure de vérification, celle-ci sera appliquée à ce stade.

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 du dépôt de données des noms de domaine (en cours d'élaboration),

xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxxxxxx-xxxx-xxxxxx

(2) Les données d'enregistrement de nom de domaine (DNRD) mappage d'objets,

xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxx-xxxxxxx-xxxxxxx

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

(4) Paramètres OpenPGP,

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

(5) Interfaces de l'ICANN pour les registres et les dépositaires légaux, xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxxx-xxxxx-xxxxxxxx-xxxxxxxxxx

PARTIE B – EXIGENCES LÉGALES

1. Dépositaire légal. Avant de conclure un contrat de dépôt, l'opérateur de registre doit informer l'ICANN de l'identité du dépositaire légal et lui fournir ses coordonnées et une copie du contrat de dépôt concerné, ainsi que de tous ses amendements. De plus, avant de conclure un contrat de dépôt, l'opérateur de registre doit obtenir le consentement de l'ICANN pour (a) utiliser le dépositaire légal spécifié, et (b) signer le contrat de dépôt fourni. L'ICANN doit être expressément désignée comme tiers bénéficiaire du contrat de dépôt. L'ICANN se réserve le droit de refuser tout dépositaire légal, tout contrat de dépôt ou tout amendement, à sa seule discrétion.

2. Frais. L’opérateur de registre doit verser, ou faire verser en son nom, des

honoraires directement au dépositaire légal. Si l’opérateur de registre ne verse pas ces honoraires à la date ou aux dates prévue(s), le dépositaire légal avertira par écrit l’ICANN de ce défaut de versement et l’ICANN paiera éventuellement les honoraires non versés dans un délai de quinze (15) jours civils suivant la date de réception de la notification écrite du dépositaire légal. Le paiement des honoraires restant à verser par l'ICANN signifiera pour l'ICANN la possession d'une créance de ce montant auprès 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é. La propriété des dépôts pendant la durée du contrat de registre demeurera celle de l’opérateur de registre à tout moment. 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) desdits dépôts. Au cas 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, maintenance ou transition du TLD.

4. Intégrité et confidentialité. Le dépositaire légal 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 du dépositaire légal, (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 du dépositaire légal après envoi d’un préavis dans un délai raisonnable et durant les heures normales de travail. L'opérateur de registre et l'ICANN seront en droit de désigner un auditeur tiers pour auditer de temps en temps le respect par le dépositaire légal des spécifications techniques et de maintenance de la présente spécification 2.

Au cas où le dépositaire légal 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, le dépositaire légal s’engage à en informer 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, le dépositaire légal s’engage à leur accorder un délai suffisant pour contester ladite injonction, ladite contestation leur incombant ; sous réserve, toutefois, que le dépositaire légal ne renonce pas à ses droits de présenter sa position en rapport à ladite injonction. Le dépositaire légal

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 du dépositaire légal de frais standard ou indiqués par devis sur demande détaillée.

5. Copies. Le dépositaire légal peut être autorisé à dupliquer tout dépôt, afin de se conformer aux conditions générales du contrat de dépôt.

6. Restitution des dépôts. Le dépositaire légal 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 pour téléchargement (sauf stipulation contraire), au cas où il recevrait une demande de l'opérateur de registre à cet effet ou s'il recevait 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 de notification du dépositaire légal, comme décrit dans la partie B, articles 7.1 et 7.2 de cette spécification, dans les cinq (5) jours civils après la date prévue de réalisation du dépôt ; (a) l'ICANN a averti le dépositaire légal et l'opérateur de registre de cette situation, et (b) l'ICANN n'a pas, dans les sept (7) jours civils après cette notification, reçu la notification du dépositaire légal ; ou

6.3. l'ICANN a reçu la notification du dépositaire légal, de la manière décrite dans la partie B, articles 7.1 et 7.2 de cette spécification, concernant la vérification manquée du dernier dépôt à une date spécifique ou une notification d'un dépôt manquant, et la notification concerne un dépôt qui aurait dû être fait le dimanche (c'est à dire, un dépôt complet); (a) l'ICANN a averti l'opérateur de registre de cette réception, et (b) l'ICANN n'a pas reçu, dans les sept (7) jours civils qui suivent cette notification, la notification comme décrit dans la partie B, articles 7.1 et 7.2 de cette spécification de la part du dépositaire légal sur la vérification d'une version corrigée de ce dépôt complet ; ou

6.4. l'ICANN a reçu cinq notifications du dépositaire légal dans les trente (30) jours civils avertissant l'ICANN des dépôts manquants ou défectueux qui auraient dû être faits du lundi au samedi (à savoir un dépôt différentiel), et

(x) l'ICANN a avisé l'opérateur de registre de la réception de ces notifications, et (y) l'ICANN n'a pas, dans les sept (7) jours civils après l'envoi de la

notification à l'opérateur de registre, reçu de notification du dépositaire légal 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é ses activités de manière normale ; ou (ii) a été déclaré en faillite, est devenu insolvable ou a subi toute autre situation analogue dans le cadre légal de l'une des juridictions applicables dans le monde ; ou

6.6. L’opérateur de registre a subi une défaillance de fonctions cruciales du registre 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 de vérifications de la conformité contractuelle et opérationnelle comme spécifié dans l'article 2.11 du contrat.

Si le dépositaire légal n’a pas précédemment restitué les dépôts de l’opérateur de registre à l’ICANN ou au tiers désigné par l’ICANN, le dépositaire légal restituera tous les dépôts à l’ICANN dès l'expiration ou la résiliation du contrat de registre ou du contrat de dépôt.

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

7.1. Dans un délai de vingt-quatre (24) heures suivant la réception de chaque dépôt ou dépôt corrigé, le dépositaire légal doit vérifier le format et l'exhaustivité de chaque dépôt et fournir à l'ICANN une notification créé pour chaque dépôt. Les rapports seront délivrés 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 cette spécification.

7.2. Si le dépositaire légal découvre qu'un dépôt ne satisfait pas aux procédures de vérification ou si le dépositaire légal ne reçoit aucun dépôt régulier, le dépositaire légal 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 cette spécification) de cette non-conformité ou de la non-réception dans les vingt-quatre (24) heures après avoir reçu le dépôt non-conforme ou la

date limite de ce dépôt, le cas échéant. Dès la notification du résultat négatif de ladite vérification ou distribution, l’opérateur de registre doit entreprendre la mise en œuvre des modifications, les mises à jour et autres corrections requises pour permettre au dépôt d'être livré et de correspondre aux critères de la procédure de vérification et fournir ces correctifs au dépositaire légal dans les meilleurs délais.

8. Amendements. Le dépositaire légal et l’opérateur de registre amenderont les termes du contrat de dépôt 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. En cas de conflit entre la présente spécification 2 et le dépositaire légal, la présente spécification 2 fait foi.

9. Indemnisation. Le dépositaire légal dégage 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 désignés comme les « Indemnitaires »), absolument et définitivement, de toute responsabilité relative aux réclamations, actions, dommages, procès, responsabilités, obligations, frais, honoraires et à quelque autre dépense que ce soit, y compris des honoraires raisonnables d’avocat, qu’un tiers pourrait exercer contre l’un des Indemnitaires, en rapport avec une fausse déclaration, une négligence ou une faute du dépositaire légal, 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, la référence 5, avec le contenu suivant.

À l’avenir, l’ICANN pourra exiger d’autres modes de livraison et d’autres formats de rapport. L'ICANN s'engage à déployer des efforts commercialement raisonnables pour préserver la confidentialité des informations mentionnées dans les rapports jusqu'à trois

(3) mois après la fin du mois sur lequel porte le rapport. Sauf qu'elles soient énoncées 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 dans un fichier au format de valeurs séparées par des virgules (CSV), comme l’indique la norme RFC 4180. Le nom du fichier devra suivre le modèle « gTLD-transactions-yyyymm.csv » où « gTLD » est remplacé par le nom du gTLD ; s’il s’agit d’un IDN TLD, le libellé ASCII doit être utilisé ; « yyyymm » doit être remplacé par l’année et le mois faisant l’objet du rapport. Le fichier doit contenir les champs suivants par bureau d'enregistrement :

Nº du cham p	Nom du champ	Description
01	registrar-name	Nom de société complet 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) 9999 doit être utilisé, sinon le parrainage d'un bureau d'enregistrement IANA id doit être utilisé comme indiqué dans xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxxxxxxxx-xxx
03	total-domains	noms de domaine totaux sous parrainage dans un statut EPP quelconque mais en pendingCreate qui n'ont pas été purgés
04	total-nameservers	serveurs de noms totaux (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 ne se trouvant pas dans l'état EPP

		pendingCreate) pour une durée initiale d’un (1) an (et non supprimés pendant la période de grâce supplémentaire). Une transaction doit être déclarée dans le mois au cours duquel la période de grâce supplémentaire s'achève.
06	net-adds-2-yr	Nombre de domaines enregistrés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) pour une durée initiale de deux (2) ans (et non supprimés pendant la période de grâce supplémentaire). Une transaction doit être déclarée dans le mois au cours duquel la période de grâce supplémentaire s'achève.
07	net-adds-3-yr	Nombre de domaines enregistrés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) pour une durée initiale de trois (3) ans (et non supprimés pendant la période de grâce supplémentaire). Une transaction doit être déclarée dans le mois au cours duquel la période de grâce supplémentaire s'achève.
08	net-adds-4-yr	.Nombre de domaines enregistrés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) pour une durée initiale de quatre (4) ans (et non supprimés pendant la période de grâce supplémentaire). Une transaction doit être déclarée dans le mois au cours duquel la période de grâce supplémentaire s'achève.
09	net-adds-5-yr	« »Nombre de domaines enregistrés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) pour une durée initiale de cinq (5) ans (et non supprimés pendant la période de grâce supplémentaire). Une transaction doit être déclarée dans le mois au cours duquel la période de grâce supplémentaire s'achève.
10	net-adds-6-yr	nombre de domaines enregistrés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) pour une durée initiale de six (6) ans (et non supprimés pendant la période de grâce supplémentaire). Une transaction doit être déclarée dans le mois au cours duquel la période de grâce supplémentaire s'achève.
11	net-adds-7-yr	nombre de domaines enregistrés avec succès(c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) pour une durée initiale de sept (7) ans (et non supprimés pendant la période de grâce

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

		trois (3) ans (et non supprimés pendant la période de grâce supplémentaire) Une transaction doit être déclarée dans le mois au cours duquel la période de renouvellement ou d'auto-renouvellement s'achève.
18	net-renews-4-yr	nombre de domaines renouvelés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) automatiquement ou par commande avec une nouvelle période de renouvellement de quatre (4) ans (et non supprimés pendant la période de grâce supplémentaire) Une transaction doit être déclarée dans le mois au cours duquel la période de renouvellement ou d'auto-renouvellement s'achève.
19	net-renews-5-yr	nombre de domaines renouvelés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) automatiquement ou par commande avec une nouvelle période de renouvellement de cinq (5) ans (et non supprimés pendant la période de grâce supplémentaire) Une transaction doit être déclarée dans le mois au cours duquel la période de renouvellement ou d'auto-renouvellement s'achève.
20	net-renews-6-yr	nombre de domaines renouvelés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) automatiquement ou par commande avec une nouvelle période de renouvellement de six (6) ans (et non supprimés pendant la période de grâce supplémentaire) Une transaction doit être déclarée dans le mois au cours duquel la période de renouvellement ou d'auto-renouvellement s'achève.
21	net-renews-7-yr	nombre de domaines renouvelés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) automatiquement ou par commande avec une nouvelle période de renouvellement de sept (7) ans (et non supprimés pendant la période de grâce supplémentaire) Une transaction doit être déclarée dans le mois au cours duquel la période de renouvellement ou d'auto-renouvellement s'achève.
22	net-renews-8-yr	nombre de domaines renouvelés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) automatiquement ou par commande avec une nouvelle période de renouvellement de huit (8) ans (et non supprimés pendant la période de grâce supplémentaire) Une transaction doit être déclarée dans le mois au cours duquel la période de renouvellement ou d'auto-renouvellement s'achève.

23	net-renews-9-yr	nombre de domaines renouvelés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) automatiquement ou par commande avec une nouvelle période de renouvellement de neuf (9) ans (et non supprimés pendant la période de grâce supplémentaire) Une transaction doit être déclarée dans le mois au cours duquel la période de renouvellement ou d'auto-renouvellement s'achève.
24	net-renews-10-yr	nombre de domaines renouvelés avec succès (c'est à dire ne se trouvant pas dans l'état EPP pendingCreate) automatiquement ou par commande avec une nouvelle période de renouvellement de dix (10) ans (et non supprimés pendant la période de grâce supplémentaire) Une transaction doit être déclarée dans le mois au cours duquel la période de renouvellement ou d'auto-renouvellement s'achève.
25	transfer-gaining-successfu l	nombre de transferts de domaine initiés par ce bureau d'enregistrement qui ont été complétés avec succès (soit explicitement, soit automatiquement approuvés) et qui n'ont pas été supprimés au cours de la période de grâce de transfert. Une transaction doit être déclarée dans le mois au cours duquel la période de grâce de transfert s'achève.
26	transfer-gaining-nacked	nombre de transferts de domaine 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-successfull y	nombre de transferts de domaine initiés par un autre bureau d'enregistrement qui ont été achevés avec succès (soit explicitement, soit automatiquement approuvés)
28	transfer-losing-nacked	nombre de transferts de domaine initiés par un autre bureau d'enregistrement que ce bureau d'enregistrement a rejeté (par exemple, transfert EPP op = « rejeter »)
29	transfer-disputed-won	nombre de litiges de transfert dans lesquels ce bureau d'enregistrement a gagné (enregistré au cours du mois où la détermination a eu lieu)
30	transfer-disputed-lost	nombre de litiges de transfert que ce bureau d'enregistrement a perdu (enregistré au cours du mois où la détermination a eu lieu)
31	transfer-disputed-nodecisi on	nombre de litiges de transfert impliquant ce bureau d'enregistrement avec une scission ou aucune

		décision (enregistré au cours du mois où la détermination a eu lieu)
32	deleted-domains-grace	domaines supprimés dans la période de grâce supplémentaire (ne comprend pas les noms supprimés pendant la période en statut pendingCreate EPP). Une suppression doit être signalée dans le mois au cours duquel le nom est purgé.
33	deleted-domains-nograce	domaines supprimés en dehors de la période de grâce supplémentaire (ne comprend pas les noms supprimés pendant la période en statut pendingCreate EPP). Une suppression doit être signalée dans le mois au cours duquel le nom est purgé.
34	restored-domains	noms de domaine restaurés à partir de la période de grâce
35	restored-noreport	nombre total de noms restaurés pour lesquels le bureau d'enregistrement n'a pas envoyé un rapport de restauration
36	agp-exemption-requests	nombre total de demandes d’exemption de la période de grâce supplémentaire (AGP)
37	agp-exemptions-granted	nombre total de demandes d’exemption de la période de grâce supplémentaire (AGP) accordées
38	agp-exempted-domains	nombre total de noms affectés par les demandes d’exemption de la période de grâce supplémentaire (AGP) accordées
39	Attempted-adds	nombre de commandes de création de nom de domaine tentées (réussite et échec)

La première ligne doit comporter les noms de champs exactement comme décrit dans le tableau ci-dessus, comme une « ligne d'en-tête », tel que décrit dans l'article 2 de la RFC 4180. La dernière ligne de chaque rapport doit inclure les totaux de chaque colonne de tous les bureaux d'enregistrement, le premier champ de cette ligne doit dire « 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 RFC 4180.

2. Rapport d’activité des fonctions de registre. Ce rapport devra être établi dans un fichier au format de valeurs séparées par des virgules (CSV), comme l’indique la norme RFC 4180. Le nom de fichier devra suivre le modèle « gTLD-activity-yyyymm.csv », où « gTLD » est le nom du gTLD ; s’il s’agit d’un IDN-TLD, le libellé ASCII doit être utilisé ; «\~yyyymm\~» est 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 à la fin de la période de rapport
02	ramp-up-registrars	nombre de bureaux d'enregistrement ayant reçu un mot de passe pour accéder à la fin de la période de rapport
03	pre-ramp-up-registrars	nombre de opérateurs de registre ayant l’accès, mais qui ne sont pas encore entrés en phase d’accélération à la fin de la période de rapport
04	zfa-passwords	nombre de mots de passe d’accès au fichier de la zone active à la fin de la période de rapport
05	whois-43-queries	nombre de requêtes WHOIS (port-43) recevant une réponse au cours de la période de rapport
06	web-whois-queries	nombre de requêtes Whois Web recevant une réponse au cours de la période de rapport, sans inclure les Whois consultables
07	searchable-whois-querie s	nombre de requêtes Whois consultables recevant une réponse au cours de la période de rapport, (le cas échéant)
08	dns-udp-queries-receive d	nombre de requêtes DNS reçues par transport UDP au cours de la période de rapport
09	dns-udp-queries-respon ded	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
10	dns-tcp-queries-received	nombre de requêtes DNS reçues par transport TCP au cours de la période de rapport
11	dns-tcp-queries-respond ed	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
12	srs-dom-check	nombre de demandes de « contrôle » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
13	srs-dom-create	nombre de demandes de « création » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
14	srs-dom-delete	nombre de demandes de « suppression » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
15	srs-dom-info	nombre de demandes « d’infos » de nom de domaine SRS (EPP et toute autre interface) recevant une

Nº du champ	Nom du champ	Description
		réponse au cours de la période de rapport
16	srs-dom-renew	nombre de demandes de « renouvellement » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
17	srs-dom-rgp-restore-rep ort	nombre de demandes de « restauration » RGP de nom de domaine SRS (EPP et toute autre interface) publiant un rapport de restauration recevant une réponse au cours de la période de rapport
18	srs-dom-rgp-restore-req uest	nombre de demandes de « restauration » RGP de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
19	srs-dom-transfer-approv e	nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à approuver les transferts recevant une réponse au cours de la période de rapport
20	srs-dom-transfer-cancel	nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à annuler les transferts recevant une réponse au cours de la période de rapport
21	srs-dom-transfer-query	nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à faire une demande concernant un transfert recevant une réponse au cours de la période de rapport
22	srs-dom-transfer-reject	nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à rejeter les transferts recevant une réponse au cours de la période de rapport
23	srs-dom-transfer-reques t	nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à demander des transferts recevant une réponse au cours de la période de rapport
24	srs-dom-update	nombre de demandes de « mise à jour » de nom de domaine SRS (EPP et toute autre interface) (n’incluant pas les requêtes de restauration) recevant une réponse au cours de la période de rapport
25	srs-host-check	nombre de demandes de « contrôle » d’hôte de SRS (EPP et toute autre interface) recevant une réponse

Nº du champ	Nom du champ	Description
		au cours de la période de rapport
26	srs-host-create	nombre de demandes de « contrôle » d’hôte de SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
27	srs-host-delete	nombre de requêtes de « suppression » de contact de SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
28	srs-host-info	nombre de requêtes « d’infos » d’hôte de SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
29	srs-host-update	nombre de requêtes de « mise à jour » d’hôte de SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
30	srs-cont-check	nombre de requêtes de « contrôle » d’hôte de SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
31	srs-cont-create	nombre de requêtes de « création » de contact de SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
32	srs-cont-delete	nombre de requêtes de « suppression » de contact de SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
33	srs-cont-info	nombre de requêtes « d’infos » de contact de SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport
34	srs-cont-transfer-approv e	Nombre de requêtes de « transfert » de contact de SRS (EPP et toute autre interface) à approuver les transferts recevant une réponse au cours de la période de rapport
35	srs-cont-transfer-cancel	nombre de requêtes de « transfert » de contact de SRS (EPP et toute autre interface) à annuler les transferts recevant une réponse au cours de la période de rapport
36	srs-cont-transfer-query	nombre de requêtes de « transfert » de contact de SRS (EPP et toute autre interface) à questionner les transferts recevant une réponse au cours de la période de rapport
37	srs-cont-transfer-reject	nombre de requêtes de « transfert » de contact de SRS (EPP et toute autre interface) à rejeter les transferts recevant une réponse au cours de la

Nº du champ	Nom du champ	Description
		période de rapport
38	srs-cont-transfer-reques t	nombre de requêtes de « transfert » de contact de SRS (EPP et toute autre interface) à faire la demande des transferts recevant une réponse au cours de la période de rapport
39	srs-cont-update	nombre de requêtes de « mise à jour » de contact de SRS (EPP et toute autre interface) recevant 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, comme une « ligne d'en-tête », tel que décrit dans l'article 2 de la 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 RFC 4180.

Pour les gTLD qui font partie d'un système d'enregistrement commun à instance unique, le rapport d'activités des fonctions d'enregistrement peut inclure le contact total ou les transactions hôtes pour tous les gTLD dans le système.

SPÉCIFICATION 4

SERVICES DE PUBLICATION DE DONNÉES D’ENREGISTREMENT

1. Services d'annuaire des données d'enregistrement. Jusqu'à ce que l'ICANN exige un protocole différent, l'opérateur de registre s'engage à utiliser un service WHOIS disponible via le port 43 conformément à la norme RFC 3912 et un service

d’annuaire basé sur le Web à l'adresse <whois.nic.TLD>, fournissant un accès public gratuit par requêtes aux éléments suivants, au minimum, sous le format suivant.

L’ICANN se réserve le droit de spécifier d’autres formats et d’autres protocoles et, le cas échéant, l’opérateur de registre s’engage à mettre en œuvre ces autres spécifications dès que possible.

L'opérateur de registre doit mettre en œuvre une nouvelle norme favorisant l'accès aux données d'enregistrement du nom de domaine (SAC 051) au plus tard cent trente-cinq (135) jours après qu'elles soient demandées par l'ICANN, si : 1) l'IETF produit une norme (par exemple, si elle est publié, au moins, comme norme proposée RFC tel que spécifié dans la RFC 2026) ; et 2) sa mise en œuvre est commercialement raisonnable dans le contexte de l'ensemble des opérations du registre.

1.1. 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.2. Chaque objet 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.3. 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. Les champs spécifiés ci-dessous énoncent les exigences minimales de résultats. L'opérateur de registre peut produire des champs de données en plus de celles ayant été mentionnées ci-dessous, sous réserve de leur approbation par l'ICANN ; l'approbation ne doit pas être refusée sans motifs raisonnables.

1.5. Données des noms de domaine :

1.5.1 Format de requêtes : whois EXEMPLE.TLD

1.5.2 Format de réponse :

Nom de domaine : EXAMPLE.TLD ID du domaine : D1234567-TLD Serveur WHOIS : whois.example.tld

URL de renvoi : 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 Bureau d'enregistrement sponsor : EXAMPLE REGISTRAR LLC

Bureau d'enregistrement sponsor ID IANA : 5555555 Statut du domaine : clientDeleteProhibited

Statut du domaine : clientRenewProhibited Statut du domaine : clientTransferProhibited Statut du domaine : serverUpdateProhibited ID du titulaire : 5372808-ERL

Nom du titulaire du nom de domaine : EXAMPLE REGISTRANT Organisation du titulaire du nom de domaine : EXAMPLE ORGANIZATION rue du titulaire du nom de domaine : 000 XXXXXXX XXXXXX

Ville du titulaire du nom de domaine : VILLE EXEMPLE État / province du technicien : 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

Identifiant de l'administrateur du registre : 5372809-ERL

Nom de l'administrateur : EXAMPLE REGISTRANT ADMINISTRATIVE Organisation de l'administrateur : EXAMPLE REGISTRANT ORGANIZATION Rue de l'administrateur : 000 XXXXXXX XXXXXX

Ville de l'administrateur : VILLE EXEMPLE É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 : 5372811-ERL

Nom du technicien : EXAMPLE REGISTRAR TECHNICAL Organisation du technicien : EXAMPLE REGISTRAR LLC Rue du technicien : 000 XXXXXXX XXXXXX

Ville du technicien : VILLE EXEMPLE É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 nom : NS01.EXAMPLEREGISTRAR.TLD

Serveur de nom : NS02.EXAMPLEREGISTRAR.TLD

DNSSEC: signedDelegation DNSSEC: unsigned

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

1.6. Données de bureau d'enregistrement :

1.6.1 Format de requêtes : whois “registrar Example Registrar, Inc.”

1.6.2 Format de réponse :

Nom du bureau d’enregistrement : Example Registrar, Inc. Rue : 0000 Xxxxxxxxx Xxx

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

Pays : US

Numéro de téléphone : +1.3105551212 Numéro de télécopie : +1.3105551213 Email: xxxxxxxxx@xxxxxxx.xxx

Serveur WHOIS : whois.example-registrar.tld URL de renvoi : xxxx://xxx.xxxxxxx-xxxxxxxxx.xxx Contact de l'administrateur : Xxx Registrar Numéro de téléphone : +1.3105551213

Numéro de télécopie : +1.3105551213 Email: xxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx Contact de l'administrateur : Xxxx Registrar Numéro de téléphone : +1.3105551214 Numéro de télécopie : +1.3105551213 Email: xxxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx Contact technique : Xxxx Xxxx

Numéro de téléphone : +1.3105551215 Numéro de télécopie : +1.3105551216 Email: xxxxxxxx@xxxxxxx-xxxxxxxxx.xxx

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

1.7. Données du serveur de noms :

1.7.1 Format de requêtes : whois “NS1.EXAMPLE.TLD”, whois “nameserver (nameserver name)”, ou whois “nameserver (IP Address)”

1.7.2 Format de réponse :

Nom du serveur : NS1.EXAMPLE.TLD Adresse IP : 192.0.2.123

Adresse IP : 2001:0DB8::1

Bureau d'enregistrement : Example Registrar, Inc. Serveur WHOIS : whois.example-registrar.tld

URL de renvoi : xxxx://xxx.xxxxxxx-xxxxxxxxx.xxx

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

1.8. 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 électronique, 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.9. Afin d'être compatible avec l'interface commune de l'ICANN pour WHOIS (InterNIC), les résultats du WHOIS devront êtres dans les grandes lignes du format ci-dessus.

1.10. Facilité de recherche. Des fonctions de recherche peuvent être proposées en option dans les services d’annuaire. Si elles sont proposées par l’opérateur de registre, elles doivent respecter la spécification décrite dans cet article.

1.10.1 L’opérateur de registre proposera une facilité de recherche dans le service d’annuaire basé sur le Web.

1.10.2 L’opérateur de registre proposera des fonctions de correspondance partielle incluant au minimum les champs suivants : le nom de domaine, les contacts et le nom du bureau d'enregistrement, ainsi que le contact et l’adresse postale du bureau d'enregistrement, y compris tous les sous-champs décrits dans l’EPP (par ex., rue, ville, état ou province, etc.).

1.10.3 L’opérateur de registre proposera des fonctions de correspondance exacte au minimum dans les champs suivants : identificateur 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.10.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 : ET, OU, SAUF (AND, OR, NOT).

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

1.10.6 L’opérateur de registre : 1) mettra en œuvre les mesures appropriées afin 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é soit conforme à toutes les politiques ou législations sur la confidentialité en vigueur.

1.11. L'opérateur de registre doit fournir un lien sur le site principal pour le TLD (c'est à dire, le site web fourni à l'ICANN pour sa publication sur le site internet de l'ICANN) vers une page web désignée par l'ICANN contenant la politique WHOIS et les documents é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 (« CZDA ») qui peut être l'ICANN ou une personne désignée par l'ICANN (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 le faire 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 de l'article 2.1.2 ci-dessous ; (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 ci-dessous ou lorsque l'opérateur de registre croit raisonnablement qu'il enfreindra les termes de l'article

2.1.5. ci-dessous ; et, (c) l'opérateur de registre peut révoquer l'accès de tout utilisateur si l'opérateur de registre a des preuves que l'utilisateur a enfreint les termes de l'article 2.1.5 ci-dessous.

2.1.2 Exigences d'identification. L’opérateur de registre, par l’intermédiaire du fournisseur CZDA, peut exiger que chaque utilisateur lui fournisse des informations suffisantes pour identifier correctement 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 à travers le fournisseur CZDA) fournira le service FTP 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 pour lequel 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 fichier de xxxx xx x’xxxxxxxxx xx xxxxxxxx (xxxxxxxxxxxxxxx xx xxxxxxxxxxx CZDA) et de transférer une copie des fichiers de zone de domaine de premier

niveau, ainsi que tout fichier chiffré de contrôle associé pas plus d’une fois par période de 24 heures, via FTP ou tout autre protocole d'accès et de transfert 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 plus haut niveau appelé

<zone>.zone.gz, avec <zone>.gz.md5 et <zone>.zone.gz.sig pour

vérifier les téléchargements. 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>-yyyymmdd.zone.gz, etc.

2.1.4 Norme de format de fichiers. L'opérateur de registre (de manière facultative à travers le 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 : <domain-name> <TTL> <class> <type> <RDATA>.

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

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, chacune 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 autorisera l'utilisateur à utiliser le fichier de zone à des fins légales, à condition que (a) l'utilisateur prenne toutes les mesures raisonnables pour garantir la protection contre l'accès non autorisé, l'utilisation et la divulgation des données, et (b) en aucun cas, l'opérateur de registre sera-t-il dans l'obligation d'autoriser l'utilisateur à utiliser les données pour (i) permettre, autoriser ou autrement prendre en charge la transmission par courrier électronique, téléphone ou télécopie de publicités ou sollicitations commerciales en masse non sollicitées aux entités autres que les propres clients de l'utilisateur, ou (ii) autoriser des processus volumineux, automatisés et électroniques qui envoient des requêtes ou des données aux systèmes d'un opérateur de registre ou à un bureau d'enregistrement accrédité par l'ICANN.

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. Co-opération

2.2.1 Assistance. 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 aux 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 en masse aux fichiers de zones pour le TLD, à l’ICANN ou à son représentant, de façon continue, tel que spécifié de temps en temps de manière raisonnable par l’ICANN. 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 00h00 UTC.

2.4. Accès de l'opérateur d'urgence. L’opérateur de registre s’engage à fournir un accès en masse 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 le spécifier de temps en temps de manière raisonnable.

3. Accès en masse aux données d’enregistrement à l’ICANN

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

d’enregistrement ainsi que de faciliter les vérifications de conformité des opérateurs de registre accrédités, l’opérateur de registre fournira à l’ICANN chaque semaine (jour spécifié par l’ICANN) des données d’enregistrement à jour telles que spécifiées ci-dessous. Ces données incluront des données enregistrées à 00h00 UTC le jour précédent le jour de récupération spécifié par l’ICANN.

3.1.1 Contenus. L’opérateur de registre fournira, au moins, les données suivantes pour tous les noms de domaines enregistrés : nom de domaine, identificateur d'objet du référentiel du nom de domaine (roid), identificateur 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 opérateurs de registre responsables du parrainage, au moins, il fournira : nom du bureau

d'enregistrement, identificateur d'objet du référentiel du bureau d'enregistrement (roid), nom d'hôte du serveur Whois du bureau d'enregistrement et URL du bureau d'enregistrement.

3.1.2 Format. Les données seront fournies au format spécifié dans la Spécification 2 du dépôt 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 un fichier de dépôt complet à la place 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êt(s) à télécharger à partir de 00h00 UTC du jour désigné pour leur récupération par l'ICANN. Le ou les fichiers seront disponibles pour le téléchargement par SFTP. L’ICANN peut exiger d’autres moyens de téléchargement dans l'avenir.

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 des tribunaux, 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 perdant. Les données seront fournies au format spécifié à la spécification 2 du dépôt de données. Le fichier contiendra uniquement les données concernant les noms de domaine du bureau d'enregistrement perdant. L'opérateur de registre fournira les données dès que ce sera commercialement possible, mais en tout cas au plus tard cinq (5) jours civils suivant la demande de l'ICANN. Sauf

convention contraire entre l’opérateur de registre et l’ICANN, 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 le paragraphe 3.1. de la présente Spécification.

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

Excepté dans la mesure où l’ICANN l’autoriserait expressément par écrit, et conformément

aux conditions générales de la présente spécification, l’opérateur de registre devra réserver des noms formés avec les étiquettes suivantes provenant de l'enregistrement initial

(c'est-à-dire non renouvelé) dans le TLD. S'il utilise l'auto-attribution, 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 “EXAMPLE” 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 appelés ici « tous les niveaux »). Ces étiquettes peuvent ne pas être activées 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 est désigné pour exploiter un TLD, tous ces identificateurs protégés devront être transférés, tel que spécifié par l'ICANN. L'opérateur de registre peut s'auto-attribuer et renouveler ce nom sans utiliser un bureau d'enregistrement accrédité par l'ICANN, ce qui ne sera pas considéré comme des transactions 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 pas être activées dans le DNS, et ne peuvent pas être libérées pour l'enregistrement à toute personne ou entité autre que l'opérateur de registre, à condition que ces chaînes d'étiquettes à deux caractères puissent être libérées dans la mesure où l'opérateur de registre parvient à un accord avec le gouvernement concerné et avec le gestionnaire de codes géographiques de la chaîne comme indiqué dans la norme ISO 3166-1 alpha-2. L'opérateur de registre peut également proposer la libération de ces réservations en fonction de la mise en œuvre de mesures pour éviter la confusion avec les codes pays correspondants, sous réserve de leur approbation par l'ICANN. Une fois qu'un opérateur de registre aura été désigné pour exploiter un TLD, toutes ces étiquettes qui sont protégées de l'enregistrement ou attribuées à l'opérateur de registre devront être transférées, tel que spécifié par l'ICANN. L'opérateur de registre peut s'auto-attribuer et renouveler ces noms sans utilisation d'un bureau d'enregistrement accrédité par l'ICANN, ce qui ne sera pas considéré comme des transactions 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 pour une 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 à tous les niveaux pour une utilisation dans le cadre de l'exploitation du registre pour le TLD : NIC. L'opérateur de registre peut activer WWW, RDDS et WHOIS dans le DNS, mais doit activer NIC dans le DNS, comme nécessaire pour le fonctionnement du TLD. Aucun des WWW, RDDS, WHOIS ou NIC ne peut être vendu ou enregistré à une personne (autre qu'un opérateur de registre) ou à un tiers. Une fois qu'un opérateur de registre aura été désigné pour exploiter un TLD, tous ces noms protégés ou attribués devront être transférés, tel que spécifié par l'ICANN. L'opérateur de registre peut s'auto-attribuer et renouveler ces noms sans utilisation d'un bureau d'enregistrement accrédité par l'ICANN, ce qui ne sera pas considéré comme des transactions aux fins de l'article 6.1 du contrat.

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 pour le fonctionnement ou la promotion du TLD. L'opérateur de registre doit agir comme titulaire du nom enregistré de ces noms tel que cela est défini dans le contrat d'accréditation du bureau d'enregistrement (RAA) alors en vigueur au sein 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 à travers un bureau d'enregistrement accrédité par l'ICANN, ou (ii) s'auto-attribuer ces noms, soumettre ces noms à l'ICANN et être responsable face à l'ICANN pour en assurer la conformité avec les politiques consensuelles de l'ICANN et les obligations énoncées dans les sous-articles 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 registre et un titulaire de nom enregistré). À la discrétion de l'opérateur de registre et dans le respect de toutes les autres dispositions du présent contrat, ces noms peuvent être libérés et être enregistrés au nom d'une autre personne ou entité.

3.3. L'opérateur de registre peut retirer de l'enregistrement ou allouer 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 pas être activés dans le DNS, mais peuvent être libérés pour être enregistrés au nom d'une autre personne ou entité à la discrétion de l'opérateur de registre. Une fois qu'un opérateur de registre aura été désigné pour exploiter un TLD, tous ces noms qui sont protégés 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 retenus ou attribuées à l'opérateur de registre, conformément à l'article 2.6 du contrat. L'opérateur de registre peut

s'auto-attribuer et renouveler ces noms sans l'utilisation d'un bureau d'enregistrement accrédité par l'ICANN, ce qui ne sera pas considéré comme des transactions aux fins de l'article 6.1 du contrat.

4. Noms de pays et de territoires. Les noms de pays et de territoires (y compris leurs variantes IDN, le cas échéant) contenus dans les listes internationalement reconnues suivantes seront exclus de l'enregistrement ou affecté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 que mise à jour de temps à autre, y compris l'Union européenne, qui est exceptionnellement réservée sur la liste ISO 3166-1, et son champ d'application étendu en août 1999 à toute application nécessitant représenter le nom de l'Union européenne

<xxxx://xxx.xxx.xxx/xxx/xxxxxxx/xxxxxxx_xxxxx/xxx_0000_xxxx_xxxxx/xxx-0 166-1_decoding_table.htm> ;

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 IDN de l'opérateur de registre, le cas échéant) puisse être libérée dans la mesure où l'opérateur de registre parvient à un accord avec le/les gouvernement/s 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 la diffusion de ces réservations soumises à la révision examen du comité consultatif gouvernemental de l'ICANN et à l'approbation de l'ICANN. Une fois qu'un opérateur de registre aura été désigné pour exploiter un TLD, tous ces noms qui sont protégés 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'auto-attribuer et renouveler ces noms sans utilisation d'un bureau d'enregistrement accrédité par l'ICANN, ce qui ne sera pas considéré comme des transactions aux fins de l'article 6.1 du contrat.

5. Comité international olympique (CIO), Croix rouge internationale et mouvement du Croissant rouge. Conformément aux instructions fournies par l'ICANN de temps à autre, les noms (y compris leurs variantes IDN, le cas échéant) se rapportant au mouvement du Comité international olympique, de la Croix-rouge et du Croissant-rouge énumérés à xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/ réservés sont exclus de l'enregistrement ou attribués à l'opérateur de registres au deuxième niveau dans le TLD. D'autres noms du mouvement du Comité international olympique, de la Croix-rouge et du Croissant-rouge (y compris leur variantes IDN) peuvent être ajoutés à la liste dans les dix (10) jours civils sur avis de 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 ces noms protégés 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'auto-attribuer et renouveler ces noms sans utilisation d'un bureau d'enregistrement accrédité par l'ICANN, ce qui ne sera pas considéré comme des transactions aux fins de l'article 6.1 du contrat.

6. Organisations intergouvernementales. Conformément aux indications fournies de temps en temps 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 identifiants des organisations intergouvernementales. Une liste des noms réservés pour cet article 6 est disponible sur xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxx. D'autres noms (y compris leurs variantes IDN) peuvent être ajoutés à la liste dix (10) jours civils après l'avis de 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 identifiants protégés devront être transférés, tel que spécifié par l'ICANN. L'opérateur de registre peut s'auto-attribuer et renouveler ces noms sans utilisation d'un bureau d'enregistrement accrédité par l'ICANN, ce qui ne sera pas considéré comme des transactions aux fins de l'article 6.1 du contrat.

SPÉCIFICATION 6

INTEROPÉRABILITÉ DU REGISTRE ET SPÉCIFICATIONS RELATIVES À LA CONTINUITÉ.

1. Conformité avec les normes

1.1. DNS. L'opérateur de registre s'engage à respecter les RFC existantes et celles publiées à l'avenir par le groupe de travail de génie Internet (IETF), notamment toutes les normes, modifications ou ajouts suivants liés au DNS et aux opérations de serveur de noms incluant, sans s'y limiter, les RFC 1034, 1035, 1123, 1982, 2181, 2182, 2671, 3226, 3596, 4343 et 5966. Les étiquettes du DNS peuvent inclure uniquement des tirets à la troisième et quatrième position si elles représentent des noms de domaine internationalisés valides dans leur encodage ASCII (par exemple

“xn--ndk061n”).

1.2. EPP. L'opérateur de registre s'engage à respecter les RFC existantes et celles publiées à l'avenir par le groupe de travail de génie Internet (IETF), notamment toutes les normes, modifications ou ajouts suivants liés à l'approvisionnement et à la gestion des noms de domaine utilisant le protocole EPP (Extensible Provisioning Protocol) en conformité avec les 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 une période de grâce de registre (Registry Grace Period, RGP), celle-ci respectera la norme RFC 5733 et suivantes. Si l'opérateur de registre requiert l'utilisation de fonctionnalités en dehors des RFC EPP de base, il doit documenter les extensions EPP au format avant-projet Internet, suivant les directives décrites dans la 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 implémentant les extensions de sécurité du système des noms de domaine

(« DNSSEC »). Pendant la durée du contrat, l'opérateur de registre s’engage à respecter les RFC 4033, 4034, 4035, 4509 et les suivantes, et à se conformer aux meilleures pratiques décrites dans la RFC 4641 et suivantes. Si l'opérateur de registre met en œuvre le déni d'existence authentifié haché (Hashed Authenticated Denial of Existence) pour le DNSSEC (DNS Security Extensions), il s'engage à respecter la RFC 5155 et suivantes. L’opérateur de registre doit accepter des éléments à 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 du DNSSEC (DPS) décrivant les procédures et les

contrôles de sécurité critiques pour le stockage principal du matériel, l’accès et l’utilisation de ses propres clés et l’acceptation sécurisée du matériel à clé

publique des titulaires de noms de domaine. L'opérateur de registre doit publier ses DPS suivant le format décrit dans la RFC 6841.

1.4. IDN. Si l'opérateur de registre propose des noms de domaine internationalisés (« IDN »), les normes RFC 5890, 5891, 5892, 5893 et suivantes doivent être respectées. L'opérateur de registre s'engage à respecter les directives de l'ICANN en matière d'IDN qui se trouvent à l'adresse

<xxxx://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, tel que spécifié dans les directives de l'ICANN en matière d'IDN.

1.5. IPv6. L’opérateur de registre doit pouvoir accepter les adresses IPv6 en tant qu’enregistrement de type glue dans son système de registre et les publier dans le DNS. L’opérateur de registre doit proposer un transport IPv6 public 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 doit suivre les « directives opérationnelles de transport de DNS IPv6 », telles qu'elles sont décrites dans le BCP 91 et les recommandations et les considérations décrites dans la RFC 4472.

L’opérateur de registre doit proposer un transport IPv6 public pour ses services de publication de données d’enregistrement, tel que défini dans la

spécification 4 de ce contrat ; par exemple, Whois (RFC 3912) et Whois basés sur le Web. L'opérateur de registre doit proposer un transport IPv6 public pour son système d'enregistrement partagé (SRS) à tout bureau d'enregistrement, au plus tard six (6) mois après la réception de la première demande par écrit d'un bureau d'enregistrement accrédité gTLD souhaitant exploiter le SRS sur IPv6.

2. Services de registre

2.1. Services de registre. Les « services de registre » sont, pour les besoins du contrat de registre, définis comme suit : (a) les services qui sont 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 ;

l’approvisionnement des bureaux d’enregistrement grâce aux états liés aux 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 contrat de registre ; et (b) d’autres produits ou services que doit fournir l’opérateur de registre du fait de l’établissement d’une politique consensuelle 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 changements déterminés apportés au services de registre dans la portée de (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, pour lesquels le requérant n'a pas fourni d'enregistrements valides tels que des enregistrements NS à lister 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 RFC 1034 et 4592 ou 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 sont demandés, les serveurs de noms publics faisant autorité doivent renvoyer une réponse « erreur de nom

» (également appelée NXDOMAIN), RCODE 3, telle que décrite dans la norme RFC 1035 et dans les 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 un affilié engagé dans la prestation de services d'enregistrement) met à jour des données, organise une telle maintenance ou perçoit des revenus de cette maintenance.

3. Continuité des registres

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 l'implémentation 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 hors du 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 hors du 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 un défaut de disponibilité du service.

3.3. Continuité de l'activité. L'opérateur de registre doit maintenir un plan de continuité de l'activité qui garantira la préservation des services de registre dans le cas d'un événement extraordinaire hors du contrôle de l'opérateur de registre ou d'un échec commercial 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 de ce fournisseur à l'ICANN. En cas d'événement extraordinaire hors du 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 contacte 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. Réduction des abus

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 principal chargé de traiter toutes les questions relatives aux problèmes de comportements malveillants dans le TLD. En outre, il informera immédiatement l'ICANN de tout changement apporté à ces informations.

4.2. Utilisation malveillante des enregistrements orphelins de type glue (Orphan Glue Records). L'opérateur de registre doit prendre des mesures pour éliminer les enregistrements orphelins de type glue (tel que définis à xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxxxxxx/xxx000.xxx) lorsqu'il détient la preuve par écrit que ces dossiers sont présents dans le cadre d'une conduite malveillante.

5. Périodes d'enregistrement initial et renouvelé acceptées

5.1. Périodes d'enregistrement initiales. 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. Pour écarter tout doute, les enregistrements initiaux des noms enregistrés ne peuvent pas 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. Pour écarter tout doute, le renouvellement des noms enregistrés ne peut pas dépasser leur période d'enregistrement de plus de dix (10) ans au moment du renouvellement.

6. Gestion de l'occurrence de collision de noms

6.1. Période de non- activation. L'opérateur de registre ne doit pas activer tous les noms dans la zone DNS pour le registre TLD (sauf dans le cas de « NIC ») jusqu'à 120 jours civils au moins après la date effective de ce contrat. L'opérateur de registre peut attribuer des noms (sous réserve du sous-article

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 registre de l'impossibilité d'activer des noms jusqu'à la fin de la période de non-activation.

6.2. Évaluation de l'occurrence de collision de noms

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 d'occurrence de collision de nom 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 collision de nom avant d'activer un nom de domaine de second niveau, ou (B) bloquer ces noms de domaine de deuxième niveau pour lesquels les mesures d'atténuation qui sont décrites dans l'évaluation d'occurrence de collision de nom 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 sous-article 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 est admissible pour cette voie alternative à l'activation de noms et (B) l'opérateur de registre bloque tous les noms de domaine de deuxième niveau identifiés par l'ICANN et établis à

<xxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxxxxx-xxx-xxxxx/xxxxxxx ement-2-17nov13-en> cette liste peut être modifiée de temps à autre par l'ICANN. L'opérateur de registre peut activer des noms en vertu du présent sous-article et, par la suite activer des noms conformément au sous-article 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 de l'ICANN de l'information du DNS, y compris sur les données « une journée dans la vie de l'Internet » conservées par le centre de recherche et d'analyse des opérations du 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 pour déterminer si ces noms bloqués peuvent être libérés et de quelle manière.

6.2.5 Si l'ICANN décide que le TLD n'est pas admissible à 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 collision de nom 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 comme une 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 collision de noms des nouveaux gTLD, approuvé par le comité du programme des nouveaux gTLD (NGPC) du Conseil de l'ICANN le 7 octobre 2013, qui est disponible à<xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxxxxxx/xxxxxxxxxxx-xxx-xxx d-annex-1-07oct13-en.pdf>.

6.3. Gestion du rapport de collision de noms

6.3.1 Pendant les deux premières années après la délégation du TLD, le service des opérations d'urgence de l'opérateur de registre doit être disponible pour recevoir des rapports, relayés par l'ICANN, alléguant un préjudice manifestement grave de collisions qui chevauchent l'utilisation 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 rapports reçus conformément au sous-article

6.3.1 en vertu duquel l'opérateur de registre peut, dans la mesure nécessaire et appropriée, supprimer un nom récemment activé de la zone de TLD pour 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 registres doit mettre en œuvre et respecter les mécanismes de protection des droits (« RPM ») spécifiés dans cette spécification. L’opérateur de registre peut é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 en abusant. L’opérateur de registre inclura tous les RPM, requis par cette spécification 7 et tout autre RPM développé et mis en œuvre par l'opérateur de registre dans le contrat opérateur de registre / bureau d'enregistrement conclu par les bureaux

d'enregistrement accrédités par l’ICANN autorisés à enregistrer des noms dans le TLD.. L'opérateur de registre doit mettre en œuvre en conformité avec les exigences qui y sont énoncées, chaque RPM obligatoire énoncé au centre d'échange d'information sur les marques à la date correspondante, telle que publiéehttp://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxx-xxxxxxxxxxxx (les « exigences du entre d'échange d'information sur les marques ») peuvent être modifiées de temps en temps par l'ICANN à certains égards immatériels.

L’opérateur de registre s’engage à n’autoriser aucun propriétaire de droits de propriété intellectuelle applicables à utiliser quelque autre service d’agrégation, de notification ou de validation d’informations de marques commerciales que ce soit, s’ajoutant ou se substituant au processus du centre d'échange d'information sur les marques désigné par l’ICANN. S'il y a un conflit entre les termes et conditions du présent contrat et les exigences du centre d'échange d'information sur les marques, les termes et conditions du présent contrat prévaudront.

2. Mécanismes de règlement de litiges. L’opérateur de registre respectera les

mécanismes suivants de règlement de litiges, à mesure de l’évolution ultérieure de ces mécanismes :

a. la procédure de règlement de litiges après délégation de la marque (PDDRP) et la procédure de règlement de litiges sur les restrictions des registres

(RRDRP) adoptées par l’ICANN (publiées sur xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx et xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/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 à l’article 4.3(e) dudit contrat) suite une détermination par tout panel PDDRP ou RRDRP, et de se conformer à une telle détermination ; et.

b. le système de suspension rapide uniforme (ci-après désigné comme l’« URS

») adopté par l’ICANN, (publié sur

xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxx), y compris la mise en œuvre des déterminations émises 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 assurer la continuité des opérations des fonctions de registre de base liées au TLD établies à l'article 6 de la spécification 10 de ce contrat pour une période de trois (3) ans suivant toute résiliation du présent contrat avant ou le jour du cinquième anniversaire de la date d’entrée en vigueur ou pour une période d’un (1) an suivant toute 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 (6) anniversaire de la date d’entrée en vigueur, et (b) devra prendre la forme soit (i) d’une lettre de garantie irrévocable, soit (ii) d’un dépôt en espèces irrévocable,

chacun devant remplir les conditions établies à l'item 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 de ces présentes (ici incorporé à la présente spécification 8 par référence). 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 de toute expiration ou 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 d'opérations continues de remplacement. L'ICANN peut tirer des fonds en vertu de la lettre de crédit initiale, si l'instrument d'opérations continues 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 devra maintenir l’ICANN informé, dans la mesure du raisonnable, de l’évolution substantielle concernant ledit instrument assurant la continuité des opérations. L’opérateur de registre ne devra pas accorder, ni

autoriser, toute modification de, ou renonciation en vertu de l’instrument assurant

la continuité des opérations ou de tout document relatif à celui-ci sans le

consentement préalable écrit de l’ICANN (qui ne doit pas être refusé sans motif raisonnable).

2. Si, nonobstant tous les efforts de l’opérateur de registre pour satisfaire ses

obligations en vertu de l’alinéa 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 promptement (i) notifier l’ICANN de l’expiration ou de la résiliation et des motifs l’expliquant et (ii) prévoir un instrument alternatif fournissant des ressources financières suffisantes afin d’assurer la continuité des opérations des fonctions de registre liées au TLD ce qui est établi dans l'article 6 de la spécification 10 du présent contrat pour une période de trois (3) ans à la suite de toute résiliation du présent contrat avant ou le jour du cinquième anniversaire de la date d’entrée en vigueur ou pour une période d’un (1) an suivant toute 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 (6) anniversaire de la date d’entrée en vigueur (ci-après, 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 sembler

acceptables à l’ICANN, dans la mesure du raisonnable.

3. Nonobstant toute disposition contraire contenue dans 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 autre instrument (i) fournissant des ressources financières suffisantes pour assurer la continuité des fonctions critiques des services de registre liés au TLD ce qui est établi dans l'article 6 de la spécification 10 du présent contrat pour une période de trois (3) ans suivant la résiliation du présent contrat ou avant ou le jour du cinquième anniversaire de la date d'entrée en vigueur ou pour une période d'un (1) an suivant toute 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 (6) 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, sachant que le fond et la forme de l'instrument alternatif doivent par ailleurs sembler acceptables à l'ICANN, dans la mesure du raisonnable. Si l’opérateur de registre remplaçait l’instrument assurant la continuité des opérations soit conformément à l’alinéa 2, soit au présent alinéa 3, les conditions de cette spécification 8 ne seront plus applicables pour ce qui est de l’instrument initial assurant la continuité des opérations, mais seront applicables au(x)dit(s) instrument(s) de remplacement, et cet instrument sera par la suite considéré l'instrument assurant la continuité pour les besoins du présent contrat.

SPÉCIFICATION 9

CODE DE CONDUITE DE L'OPÉRATEUR DE REGISTRE

1. En rapport avec l'exploitation du registre pour le TLD, l'opérateur de registre n'autorisera aucun parent, aucune filiale, aucun affilié, aucun sous-traitant, ni entité associée, dans la mesure où une telle partie est engagée dans la fourniture de services de registre à l'égard du TLD (désignés par « tiers associé au registre »), à :

a. faire preuve directement ou indirectement de toute sorte de préférence ou de 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 associés, sauf si des opportunités comparables justifiant ces préférences ou considérations étaient disponibles pour tous les bureaux d'enregistrement et pour tous les revendeurs dans des conditions similaires ;

b. enregistrer des noms de domaine dans son propre 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 des noms de l'enregistrement conformément à l'article 2.6 du contrat et (b) retirer de l'enregistrement ou affecter à l'opérateur de registre jusqu'à cent

(100) noms conformément à l'article 3.2 de la spécification 5 ;

c. les noms de registre dans les TLD ou les sous-domaines des TLD basés sur l’accès à l’information exclusive concernant les recherches ou les résolutions de litiges par les consommateurs pour les noms de domaine n’étant pas encore enregistrés (normalement connus comme « 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 était raisonnablement nécessaire à des fins de gestion et d'opération du TLD, à moins que les tiers non associés (y compris d'autres opérateurs de registre) bénéficient d'un accès égal à de telles données de l'utilisateur dans des conditions et des termes substantiellement similaires.

2. Si un opérateur de registre ou un tiers associé au registre agissait en tant que fournisseur de services de bureau d'enregistrement ou de revendeur-bureau d'enregistrement, l'opérateur de registre se chargera de, ou chargera ledit tiers associé au registre d'assurer que ces services soient offerts à travers une entité séparée de l'opérateur de registre et de maintenir des livres de comptes distincts conformément à ses opérations de bureau d'enregistrement ou de

revendeur-bureau d'enregistrement.

3. Si l'opérateur de registre ou une partie liée au registre fonctionne également comme un fournisseur de bureau d'enregistrement ou comme un service 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 civile, l'opérateur de registre fournira les résultats des tests internes, ainsi que la certification exécutée par un agent administratif 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 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 ici mentionnée ne doit : (i) empêcher l'ICANN de mener des investigations en cas de réclamation pour non-conformité de l'opérateur de registre avec ce code de conduite ; ou (ii) indiquer des motifs de refus de coopération de l'opérateur de registre avec les investigations 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 ici mentionnée ne doit empêcher l'opérateur de registre ou tout tiers associé au registre de conclure des transactions avec lien de dépendance dans le cadre d'activités normales menées avec un bureau d'enregistrement ou un vendeur 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 à la discrétion raisonnable de l'ICANN, 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 affiliés, (ii) l'opérateur de registre ne vend pas, ne distribue pas et ne transfère pas le contrôle ou l'utilisation de tout enregistrement dans le TLD à un tiers qui n'est pas un affilié à 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.

SPÉCIFICATION 10 SPÉCIFICATIONS DE PERFORMANCE DU REGISTRE

1. Définitions

1.1. DNS. Désigne le système de noms de domaine comme spécifié dans les RFC 1034, 1035, et les RFC correspondantes.

1.2. DNSSEC résolution appropriée. Il y a une chaîne de confiance DNSSEC valide de l'ancre de confiance de la racine à un nom de domaine particulier, par exemple, un TLD, un nom de domaine enregistré sous un TLD, etc.

1.3. EPP. Fait référence au protocole d'avitaillement extensible tel que spécifié dans la RFC 5730 et les RFC correspondantes.

1.4. Adresse IP. Fait référence à des adresses IPv4 ou IPv6 sans faire de distinction entre les deux. Quand il est nécessaire de faire une distinction, IPv4 ou IPv6 est utilisé.

1.5. Sondes. Les serveurs du réseau qui sont situés à des emplacements divers du monde, effectuent des tests (DNS, EPP, etc.) (voir ci-dessous).

1.6. RDDS. Les services de répertoire de données d’enregistrement (Registration Data Directory Services) font référence à la convention collective du WHOIS et des services WHOIS basés sur le web, tel que définis dans la spécification 4 du présent contrat.

1.7. RTT. Temps d'aller-retour ou RTT (Round Trip Time) fait allusion au temps mesuré à partir de l'envoi du premier bit du premier paquet de la séquence de paquets nécessaires pour faire une requête jusqu'à la réception du dernier bit du dernier paquet de la séquence nécessaire pour recevoir la réponse. Si le client ne reçoit pas toute la séquence de paquets nécessaires pour considérer la réponse comme reçue, la demande sera considérée comme

non-répondue.

1.8. SLR. Le niveau de service requis est le niveau de service attendu d'un certain paramètre qui est mesuré dans une convention de service (Service Level Agreement - SLA).

2. Matrice de la convention de service

	Paramètre	SLR (base mensuelle)
DNS	Disponibilité du service DNS	0 min de temps d’arrêt = 100 % disponibilité
	Disponibilité du serveur de noms DNS	 432 min de xxxxx x’xxxxx (x 00 %)

	RTT de résolution DNS sur TCP	 1500 ms, pour au moins 95 % des requêtes
	RTT de résolution DNS sur UDP	 500 ms, pour au moins 95 % des requêtes
	Temps de mise à jour du DNS	 60 min, pour au moins 95 % des sondes
RDDS	Disponibilité RDDS	 864 min de xxxxx x’xxxxx (x 00 %)
	requête RTT-RDDS	 2000 ms, pour au moins 95 % des requêtes
	Temps de mise à jour RDDS	 60 min, pour au moins 95 % des sondes
EPP	Disponibilité du service EPP	 864 min de xxxxx x’xxxxx (x 00 %)
	Session EPP-commande RTT	 4000 ms, pour au moins 90 % des commandes
	RTT de commande de requête EPP	 2000 ms, pour au moins 90 % des commandes
	RTT de commande de transformation EPP	 4000 ms, pour au moins 90 % des commandes

L'opérateur de registre est encouragé à faire la maintenance pour les différents services dans les délais et dates où la circulation est statistiquement plus réduite pour chaque service. Toutefois, notez qu'il n'y a aucune disposition pour les interruptions de service planifiées ou similaires; tout temps d'arrêt, que ce soit pour la maintenance ou en raison de défaillances du système, sera noté simplement comme temps d'arrêt et compté aux fins du SLA.

3. DNS

3.1. Disponibilité du service DNS. Désigne la capacité du groupe de serveurs de noms avec autorité pour un nom de domaine particulier (par exemple, un TLD), de répondre à des demandes DNS à partir de sondes DNS. Pour que le service soit considéré comme étant disponible à un moment donné, au moins deux des serveurs de noms délégués enregistrés dans le DNS doivent avoir de bons résultats des « essais DNS » à chacun de leurs « adresses IP » du DNS enregistré publiquement, pour lequel le serveur de noms résout. Si 51

% ou plus des sondes d'essai DNS voient le service comme étant indisponible pendant une période donnée, le service DNS sera considéré comme

non-disponible.

3.2. Disponibilité du service de noms DNS. Désigne la capacité d'une « adresse IP » d'un DNS enregistré publiquement d'un serveur de nom particulier répertorié comme faisant autorité pour un nom de domaine, pour répondre à des requêtes DNS d'un utilisateur d'Internet. Toutes les « adresses IP » de DNS enregistrés publiquement de tous les serveurs de noms du nom de domaine qui sont objet d'une surveillance doivent être testées individuellement. Si 51 % ou plus des sondes d'essai DNS obtiennent des résultats des « essais DNS » indéfini/sans à un serveur de nom « adresse

IP » pendant une période donnée, le serveur de nom « adresse IP » sera considéré comme non-disponible.

3.3. RTT de résolution DNS sur UDP. Fait référence à la RTT de la séquence de deux paquets, la demande DNS UDP et la réponse UDP DNS correspondante. Si la RTT est 5 fois plus grande que la durée spécifiée dans la SLR pertinente, la RTT sera considérée comme non définie.

3.4. RTT de résolution DNS sur TCP. Fait référence à la RTT de la séquence des paquets à partir du début de la connexion TCP jusqu'à sa fin, y compris la réception de la réponse DNS pour une seule requête DNS. Si la RTT est 5 fois plus grande que la durée spécifiée dans la SLR pertinente, la RTT sera considérée comme non définie.

3.5. Résolution RTT-DNS. Désigne soit la « RTT de résolution DNS sur UDP »

soit la « RTT de résolution DNS sur TCP ».

3.6. Temps de mise à jour du DNS. Correspond à la période mesurée à partir de la réception d'une confirmation de l'EPP à un ordre transformation d'un nom de domaine, jusqu'à ce que les serveurs de nom du nom de domaine parent répondent les « requêtes DNS » avec des données cohérentes avec la modification apportée. Cela s'applique uniquement aux changements à l'information du DNS.

3.7. Test DNS. Signifie une requête DNS non récursive envoyée à une « adresse IP » particulière (via UDP ou TCP). Si le DNSSEC est proposé dans la zone

DNS demandée, pour qu’une demande soit considérée comme étant sans réponse, les signatures doivent être vérifiées positivement avec un enregistrement DS correspondant publié dans la zone parent ou, si le parent n’est pas signé, avec une autorité de certification configurée statiquement. La réponse à une requête doit contenir les informations correspondantes du système de registre, sinon la requête sera considérée comme étant sans réponse. Une demande avec une « RTT de résolution DNS » 5 fois plus élevée que le SLR correspondant, sera considérée comme étant sans réponse. Les résultats possible à un test de DNS sont les suivants : un nombre en millisecondes correspondant à la « RTT de résolution DNS » ou, indéfini / sans réponse.

3.8. Paramètres de mesurage du DNS. Chaque minute, chaque sonde DNS fera un « test DNS » UDP ou TCP à chacune des « adresses IP » des DNS enregistrés publiquement des serveurs de noms du nom de domaine à surveiller. Si le résultat de « test DNS » est indéfini/sans réponse, la période d'enquête testée sera considéré comme indisponible à partir de cette sonde jusqu'à ce qu'il soit temps de faire un nouveau test.

3.9. Rassembler les résultats des sondes DNS. Le nombre minimal de sondes de tests actives pour envisager une mesure valide est de 20 à n'importe quelle période de mesure donnée, sinon les mesures seront perdues et seront

considérées comme non concluantes. Au cours de cette situation aucune faute ne sera signalée contre les SLR.

3.10. Distribution des requêtes UDP et TCP. Les sondes DNS enverront un

« test DNS » UDP ou TCP lorsque la distribution de ces requêtes approche.

3.11. Placement des sondes DNS. Des sondes pour les paramètres de mesurage DNS doivent être placées aussi près que possible du résolveur DNS sur les réseaux avec la plupart des utilisateurs dans les différentes régions géographiques ; il faut prendre soin de ne pas déployer des sondes derrière les liens de haute propagation de délais, tel que les liens satellite.

4. RDDS

4.1. Disponibilité RDDS. Désigne la capacité de tous les services RDDS pour le TLD, de répondre aux requêtes effectuées par un utilisateur d'Internet avec les données du système de registre appropriées. Si 51 % ou plus des sondes d'essai RDDS voient l'un de ces services RDDS comme étant indisponible pendant un temps donné, le service RDDS sera considéré comme

non-disponible.

4.2. Requête RTT-WHOIS. Fait référence à la RTT de la séquence des paquets entre le début de la connexion TCP et sa fin, y compris la réception de la réponse du WHOIS. Si la RTT est équivalente ou dépasse 5 fois le SLR correspondant, la RTT sera considérée comme étant non définie.

4.3. Requête RTT du WHOIS basé sur le Web. Fait référence à la RTT de la séquence des paquets entre le début de la connexion TCP et sa fin, y compris la réception de la réponse HTTP pour une seule requête HTTP. Si l’opérateur de registre implémente un processus à plusieurs étapes pour obtenir des informations, seule la dernière étape sera mesurée. Si la RTT est équivalente ou dépasse 5 fois le SLR correspondant, la RTT sera considérée comme étant non définie.

4.4. Requête RTT-RDDS. Concerne la convention collective des « requêtes RTT WHOIS » et « requête RTT WHOIS basée sur le Web ».

4.5. Temps de mise à jour du RDDS. Correspond à la période mesurée à partir de la réception d'une confirmation d'un EPP à un ordre de transformation sur un nom de domaine, d'hôte ou de contact, jusqu'à ce que les serveurs des services RDDS reflètent les modifications apportées.

4.6. Test RDDS. Signifie une requête envoyée à une « adresse IP » spécifique de l'un des serveurs de l'un des services RDDS. Les requêtes doivent concerner des objets existants du système de registre, et les réponses doivent contenir les informations correspondantes, auquel cas la requête sera considérée comme étant sans réponse. Les requêtes dont la RTT est 5 fois supérieure au

SLR correspondant seront considérées comme étant sans réponse. Les résultats possibles d'un test de RDDS sont les suivants : un nombre en millisecondes correspondant à la RTT ou, indéfini / sans réponse.

4.7. Paramètres de mesurage du RDDS. Toutes les 5 minutes, les sondes RDDS choisiront une adresse IP de toutes les « adresses IP » des DNS enregistrés publiquement des serveurs pour chaque service RDDS du TLD faisant l'objet d'un suivi et font un « test RDDS » à chacun d'eux. Si un résultat du « test RDDS » est indéfini / sans réponse, le service RDDS correspondant sera considéré comme indisponible à partir de cette sonde jusqu'à ce qu'il soit temps de faire un nouveau test.

4.8. Rassemblement des résultats des sondes RDDS. Le nombre minimal de sondes de tests actives pour envisager une mesure valide est de 10 à n'importe quelle période de mesure donnée, sinon les mesures seront perdues et seront considérées comme non concluantes. Au cours de cette situation aucune faute ne sera signalée contre les SLR.

4.9. Placement de sondes RDDS. Des sondes pour les paramètres de mesurage RDDS doivent être placées dans les réseaux ayant le plus d'utilisateurs dans les différentes régions géographiques; faisant attention à ne pas déployer les sondes derrière les liens de délai de haute propagation, tels que les liens satellite.

5. EPP

5.1. Disponibilité du service EPP. Désigne la capacité des serveurs du TLD EPP en tant que groupe, de répondre aux commandes des bureaux d'enregistrement accrédités par le registre, qui ont déjà des informations d'identification sur les serveurs. La réponse doit inclure les données appropriées du système de registre. Un ordre EPP avec « commande

RTT-EPP » 5 fois plus élevée que la SLR correspondante sera considérée comme étant sans réponse. Si 51 % ou plus des sondes d'essai EPP voient le service EPP comme étant indisponible pendant une période donnée, le service DNS sera considéré comme non-disponible.

5.2. Session EPP-commande RTT. Fait référence à la RTT de la séquence de paquets qui comprend l'envoi d'une commande de session ainsi que la réception de la réponse EPP pour une seule commande de session EPP. Pour une commande de connexion, il inclura les paquets requis pour démarrer la session TCP. Pour une commande de déconnexion, il inclura les paquets requis pour fermer la session TCP. Les commandes de session EPP sont décrites dans l’article 2.9.1 de la RFC EPP 5730. Si la RTT est équivalente ou dépasse 5 fois le SLR correspondant, la RTT sera considérée comme étant non définie.

5.3. RTT de commande de requête EPP. Fait référence à la RTT de la séquence de paquets qui comprend l'envoi d'une commande de requête ainsi que la réception de la réponse EPP pour une seule commande de requête EPP. Il n'inclut pas les paquets nécessaires au démarrage ou à la clôture soit de l'EPP ou de la session TCP. Les commandes de requête EPP sont décrites dans l’article 2.9.2 de la RFC EPP 5730. Si la RTT est équivalente ou dépasse 5 fois le SLR correspondant, la RTT sera considérée comme étant non définie.

5.4. RTT de commande de transformation EPP. Fait référence à la RTT de la séquence de paquets qui comprend l'envoi d'une commande de transformation ainsi que la réception de la réponse EPP pour une seule commande de transformation EPP. Il n'inclut pas les paquets nécessaires au démarrage ou à la clôture soit de l'EPP ou de la session TCP. Les commandes de transformation EPP sont décrites dans l’article 2.9.3 de la RFC EPP 5730. Si la RTT est équivalente ou dépasse 5 fois le SLR correspondant, la RTT sera considérée comme étant non définie.

5.5. Commande EPP-RTT. Fait référence à « RTT de commande de session EPP », « demande EPP-commande RTT » ou « RTT de commande de transformation EPP ».

5.6. Test EPP. Signifie qu'une commande EPP a envoyé à une « adresse IP » particulière pour l'un des serveurs EPP. Les commandes de transformation et de requête, à l’exception de « créer », doivent concerner des objets existants du système de registre. La réponse doit inclure les données appropriées du système de registre. Les résultats possibles à un test EPP sont les suivants : un nombre en millisecondes correspondant à la

« commande EPP-RTT » ou, indéfini/sans réponse.

5.7. Paramètres de mesurage de l'EPP. Toutes les 5 minutes, les sondes PPE sélectionneront une « adresse IP » des serveurs EPP du TLD objet d'un suivi et font un « test EPP » ; chaque fois ils devraient alterner entre les 3 différents types de commande et entre les ordres à l'intérieur de chaque catégorie. Si le résultat d'un « test EPP » est indéfini/sans réponse, le service EPP correspondant sera considéré comme indisponible à partir de cette sonde jusqu'à ce qu'il soit temps de faire un nouveau test.

5.8. Rassembler les résultats des sondes EPP. Le nombre minimal de sondes de tests actives pour envisager une mesure valide est de 5 à n'importe quelle période de mesure donnée, sinon les mesures seront perdues et seront considérées comme non concluantes. Au cours de cette situation aucune faute ne sera signalée contre les SLR.

5.9. Placement des sondes EPP. Des sondes pour les paramètres de mesurage EPP doivent être placées dans ou à proximité des points d'accès à l'Internet des bureaux d'enregistrement dans les différentes régions géographiques ;

on doit prendre soin de ne pas déployer des sondes derrière les liens de haute propagation de délai, tels que les liens satellite.

6. Seuils d'urgence

La matrice suivante présente les seuils d'urgence qui, s'ils sont atteints par l'un des services mentionnés ci-dessus pour un TLD, serait la cause de la transition d'urgence du registre pour le TLD comme spécifié à l'article 2.13. du présent contrat.

Fonction critique	Seuil d'urgence
Service DNS (tous les serveurs)	Temps d'arrêt de 4 heures / semaine
DNSSEC résolution appropriée	Temps d'arrêt de 4 heures / semaine
EPP	Temps d'arrêt de 24 heures / semaine
RDDS (WHOIS/WHOIS basés sur le web)	Temps d'arrêt de 24 heures / semaine
Dépôt de données	Infraction au contrat de registre causée par manque de dépôts fiduciaires comme décrit dans la spécification 2, partie B, article 6.

7. Intervention progressive d'urgence

L’intervention progressive est strictement à des fins de notification et d'enquêter sur les problèmes possibles ou potentiels par rapport aux services surveillés. L'initiation de toute intervention progressive et les investigations coopératives n'impliquent pas, en

elles-mêmes, qu'un service surveillé n'ait pas respecté ses exigences de performance.

Les interventions progressives sont effectuées entre l'ICANN et les opérateurs de registre, entre les bureaux d'enregistrement et l'opérateur de registre et entre les bureaux d'enregistrement et l'ICANN. Les opérateurs de registre et l'ICANN doivent fournir lesdits départements d'opérations d'urgence. Des contacts courants doivent être maintenus entre l'ICANN et les opérateurs de registre et publié aux bureaux d'enregistrement suivant leur rôle dans l'intervention progressive, avant tout traitement d'une intervention progressive d'urgence par toutes les parties liées, et tenus à jour en tout temps.

7.1. L’intervention progressive d'urgence lancée par l'ICANN

Après avoir atteint 10 % des seuils d'urgence tels que décrits dans l'article 6 de la présente spécification, les opérations d'urgence de l'ICANN vont ouvrir une intervention progressive d'urgence avec l'opérateur de registre pertinent. Une intervention progressive d'urgence se compose au moins des éléments suivants : électroniques (c.-à-dire courriel ou SMS) et/ou notification de contact par voix au département d'opérations d'urgence de l'opérateur de registre contenant des renseignements détaillés concernant la question à

l'intervention progressive, y compris la preuve des défaillances de contrôle, d'une coopérative de dépannage de l'échec de surveillance entre le personnel de l'ICANN et l'opérateur de registre et l'engagement de commencer le processus de rectification des problèmes soit avec le service de surveillance ou de contrôle de service qui est contrôlé.

7.2. L’intervention progressive d'urgence lancée par les bureaux d'enregistrement

L'opérateur de registre maintiendra un département d'opérations d'urgence prêt à traiter les demandes d'urgence des bureaux d'enregistrement. Au cas où un bureau d'enregistrement ne serait pas en mesure de mener des transactions EPP avec le registre pour le TLD à cause d'une panne avec le service de registre et qu'il est incapable de communiquer avec (par le biais de l'ICANN chargé des méthodes de communication) l'opérateur de registre, ou que le l'opérateur de registre est incapable ou refuse d'adresser la faute, le bureau d'enregistrement peut engager une intervention progressive d'urgence au département d'opérations d'urgence de l'ICANN. L'ICANN peut alors engager une intervention progressive d'urgence avec l'opérateur de registre comme expliqué ci-dessus.

7.3. Notifications de pannes et de maintenance

Dans le cas où un opérateur de registre planifie une maintenance, il fournira des avis relatifs au département d'opérations d'urgence de l'ICANN, au moins 24 heures à l'avance de cette maintenance. Le département d'opérations d'urgence de l'ICANN notera les temps prévus de maintenance, et suspendra les services d'intervention progressive d'urgence pour les services de suivi au cours de la période d'arrêt de maintenance prévue.

Si l'opérateur de registre déclare une panne, conformément à ses obligations contractuelles avec l'ICANN, des services sous les exigences d'un contrat de niveau de service et de performance, il en informera le département des opérations d'urgence de l'ICANN. Au cours de cette panne déclarée, le département des opérations d'urgence de l'ICANN notera et suspendra les services d'intervention progressive d'urgence pour les services de surveillance concernés.

8. Conventions de mesurage du rendement

8.1. Aucune interférence. L'opérateur de registre ne doit pas interférer avec les sondes de mesurage, y compris toute forme de traitement préférentiel de la demande pour les services surveillés. L'opérateur de registre doit répondre aux tests de mesurage décrits dans cette spécification comme il le ferait avec toute autre demande d'un utilisateur d'Internet (pour le DNS et le RDDS) ou de bureaux d'enregistrement (pour l'EPP).

8.2. Bureau d'enregistrement de testage de l'ICANN. L'opérateur de registre accepte que l'ICANN ait un bureau d'enregistrement de testage utilisé à des fins de mesurage des SLR décrit ci-dessus. L'opérateur de registre s'engage à ne pas fournir un traitement différencié pour le bureau d'enregistrement de testage autre que pour la facturation des transactions. L'ICANN n'utilisera

pas le bureau d'enregistrement pour l'enregistrement de noms de domaine (ou d'autres objets de registre) pour lui-même ou des tiers, sauf aux fins de vérifier la conformité contractuelle avec les conditions décrites dans le présent contrat.