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 »).
DÉLÉGATION ET FONCTIONNEMENTDES 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.
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 constitutifs 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. À son entière 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 constitutifs 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 Entiercement de données. L’opérateur de registre devra être conforme aux procédures d’entiercement de données des registres définies à la spécification 2 jointe à ces présentes (« spécification 2 ») dans les (14) jours calendaires après la délégation.
2.4 Élaboration de rapports mensuels. Dans les vingt (20) jours calendaires suivant la fin de chaque mois civil, à compter du premier mois civil au cours duquel le TLD est délégué dans la zone racine, l’opérateur de registre doit remettre à l’ICANN les rapports dans le format indiqué dans la spécification 3 ci-jointe ( « spécification 3 ») ; à condition, toutefois, que si le TLD est délégué dans la zone racine après le quinzième (15e) jour civil du mois civil, l’opérateur de registre peut remettre la remise des rapports pour ce premier mois civil et remettre les rapports de ce mois à l’ICANN au plus tard au moment auquel il est tenu de remettre les rapports pour le mois civil immédiatement suivant. L’opérateur de registre doit inclure dans le rapport des transactions par bureau d’enregistrement tout nom de domaine créé au cours des tests de pré-délégation n’ayant pas été supprimé au moment de la délégation (notamment, mais sans s’y limiter, des domaines enregistrés par les ID de bureau d’enregistrement 9995 et / ou 9996).
2.5 Publication des données d’enregistrement. L’opérateur de registre devra fournir un accès public aux données d’enregistrement conformément à la spécification 4 jointe à 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 calendaires, 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 calendaires, 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 oeuvre 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. Nonobstant les dispositions précédentes du présent article 2.9(a), toute
modification du contrat de registre ou de bureau d’enregistrement qui se rapporte exclusivement aux frais facturés par l’opérateur de registre pour l’enregistrement de noms de domaine dans le TLD ne feront pas l’objet de la procédure de notification et
d’approbation spécifié dans le présent article 2.9(a) mais devra plutôt suivre les dispositions de l’article 2.10 ci-dessous.
(b) Si l’opérateur de registre (i) devient affilié ou revendeur d’un bureau d’enregistrement accrédité par l’ICANN, ou (ii) 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 à 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 calendaires 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 de registre bureau d’enregistrementcontrat 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-vingts (180) jours calendaires 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 calendaires 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-vingts(180) jours calendaires (avec les programmes consécutifs similaires regroupés dans le but de déterminer le nombre de jours calendaires 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) 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 é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 à caractère personnel. L’opérateur de registre devra (i) notifier à chaque bureau d’enregistrement accrédité par l’ICANN et faisant partie d’un contrat de registre-bureau d’enregistrementcontrat registre-bureau d’enregistrement pour le TLD aux fins duquel les données concernant toute personne physique identifiée ou identifiable
(« données à caractère personnel ») 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 à caractère
personnel, 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 à caractère personnel. L’opérateur de registre prendra toutes les mesures raisonnables pour protéger les données à caractère personnel collectées dudit bureau d’enregistrement contre la perte, l’utilisation malveillante, 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 à caractère personnel 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,
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.
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 calendaires 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.
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 calendaires 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 calendaires 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 calendaires 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 douze (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 calendaires 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 calendaires 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 calendaires 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 calendaires à 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 qui, si elle était imposée, pourrait raisonnablement avoir un effet négatif sur la capacité de l’opérateur de registre d’exploiter le registre pour le TLD(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 calendaires à compter de leur initiation (si ces procédures étaient instituées par
l’opérateur de registre ou ses filiales) un cent quatre-vingts (180) jours calendaires à compter de leur initiation (si ces procédures étaient instituées par un tiers contre l’opérateur de registre), 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 calendaires adressé à l’opérateur de registre, résilier ce contrat conformément à une détermination
d’un panel PDDRP ou RRDRP conformément à l’article 2 de la spécification 7 ou articlesune détermination par un panel PICDRP conformément à l’article 2, et, l’article 3 ou tout autre article applicable de la spécification 11, sous réserve du droit de l’opérateur de registre de contester une telle 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 emploie délibérément un cadre qui a été reconnu coupable d’un crime ou d’un délit lié à des activités financières ou de tout autre
crime, ou s’il a été jugé coupable de fraude ou de manquement à un devoir fiduciaire par un
tribunal de juridiction compétente, ou s’il a fait l’objet d’une décision judiciaire que l’ICANN estime équivaloir en substance à l’un des cas ci-dessus et que ce cadre n’est pas congédié dans les trente (30) jours calendaires à 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 a été
reconnu coupable d’un crime ou d’un délit lié à des activités financières ou de tout autre crime, ou a été jugé par un tribunal de juridiction compétente coupable de fraude ou de manquement à un devoir fiduciaire, ou a fait l’objet d’une décision judiciaire que l’ICANN estime équivaloir en substance à 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 calendaires à 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 calendaires, résilier le présent contrat conformément à l’article 7.5.
(h) [Uniquement applicable aux organisations intergouvernementales ou aux entités gouvernementales]. L’ICANN peut résilier le présent contrat conformément à l’article 7.16.
4.4 Résiliation par l’opérateur de registre.
(a) L’opérateur de registre peut 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 calendaires 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 calendaires 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 calendaires à 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 confusion, 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 ce contrat, 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 contrat. Afin d’éviter toute confusion, 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.
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 calendaires 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 calendaires 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 lui n’ayant pas été résolus conformément à l’article 5.1, y compris les demandes de résultats spécifiques, 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’« ICC »). L’arbitrage sera réalisé en anglais et aura lieu dans le comté de Los Angeles, en Californie. Tout arbitrage aura lieu face à un arbitre unique sauf si (i) l’ICANN 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 sélectionnantdésignant un arbitre qui sera confirmé par l’ICC et les deux arbitres désignés sélectionnantdésignant à leur tour le troisième arbitre qui sera confirmé par l’ICC. Dans le cas d’un arbitrage devant un arbitre unique, l’opérateur de registre et l’ICANN peuvent, d’un commun accord, désigner un arbitre unique pour sa confirmation par l’ICC. Si les parties ne désignent pas un arbitre unique ou, dans le cas d’un arbitrage devant trois
arbitres, l’une des parties ne désigne pas un arbitre, dans chaque cas, dans les trente (30) jours calendaires à compter de la date à laquelle la demande d’une partie à l’arbitrage a été reçue par l’autre partie, ou dans le délai supplémentaire susceptible d’être accordé par le Secrétariat de la Cour de l’ICC, le ou les arbitre(s) sera/seront nommé(s) par l’ICC. Si un
arbitre désigné n’est pas confirmé par l’ICC, la partie ou les personnes ayant nommé cet arbitre désigneront rapidement un arbitre de remplacement pour sa confirmation par l’ICC. Afin d’accélérer l’arbitrage et d’en limiter les coûts, l’arbitre ou les arbitres établiront des limites 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 lui n’ayant pas été résolus conformément à l’article 5.1, y compris les demandes de résultats spécifiques, 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’« ICC »). L’arbitrage sera réalisé en anglais et aura lieu à Genève, en Suisse, sauf si un autre lieu est mutuellement convenu par l’opérateur de registre et l’ICANN. Tout arbitrage aura lieu face à un arbitre unique sauf si (i) l’ICANN 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 sélectionnantdésignant un arbitre qui sera confirmé par l’ICC et les deux arbitres désignés sélectionnantdésignant à leur tour le troisième arbitre qui sera confirmé par l’ICC. Dans le cas d’un arbitrage devant un arbitre unique, l’opérateur de registre et l’ICANN peuvent, d’un commun accord, désigner un arbitre unique pour sa confirmation par l’ICC. Si les parties ne désignent pas un arbitre unique ou, dans le cas d’un arbitrage devant trois arbitres, l’une des parties ne désigne pas un arbitre, dans chaque cas, dans les trente (30) jours calendaires à compter de la date à laquelle la demande d’une
partie à l’arbitrage a été reçue par l’autre partie, ou dans le délai supplémentaire susceptible d’être accordé par le Secrétariat de la Cour de l’ICC, le ou les arbitre(s)
sera/seront nommé(s) par l’ICC. Si un arbitre désigné n’est pas confirmé par l’ICC, la partie
ou les personnes ayant nommé cet arbitre désigneront rapidement un arbitre de
remplacement pour sa confirmation par l’ICC. Afin d’accélérer l’arbitrage et d’en limiter les coûts, l’arbitre ou les arbitres établiront des limites 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 la section 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).
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 calendaires é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 calendaires 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 calendaires à 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 calendaires pour le premier trimestre de l’exercice fiscal de l’ICANN et dans un délai de vingt (20) jours calendaires 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 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 selon le 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) 0,25 USD pour chaque enregistrement pendant la période d’enregistrement prioritaire et pour chaque enregistrement de revendication de marque (comme ces termes sont employés dans le RPM du centre d’échange d’information sur les marques 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 calendaires 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 une augmentation, l’ICANN donnera un préavis à l’opérateur de registre 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 calendaires 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.
6.7 Dérogation de la réduction des frais. À la seule discrétion de l’ICANN,
l’ICANN peut réduire le montant des frais de registre exigibles à l’opérateur de registre aux termes des présentes pour une période de temps (« dérogation de la réduction des frais »). Toute dérogation de la réduction des frais peut, suivant la détermination de l’ICANN à sa seule discrétion, être (a) d’une durée limitée et (b) conditionnée à l’acceptation de
l’opérateur de registre des termes et conditions énoncés dans cette dérogation. Une dérogation de la réduction des frais ne sera en vigueur que si elle est accordée par écrit par l’ICANN tel que prévu à l’article 7.6(i). L’ICANN fournira un avis de toute dérogation de la
réduction des frais à l’opérateur de registre conformément à l’article 7.9.
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 é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, la présente section 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 toute confusion, 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 administré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 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 calendaires 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 calendaires 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 calendaires 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 calendaires.
(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 calendaires 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 calendaires à 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 à un subsidiaire cessionnaire affilié, terme défini ci-après dans ces présentes après la prise en fonction expresse écrite du cessionnaire affilié ou du parent, le cas échéant, 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. Aux fins du présent article 7.5(f), (A) « cessionnaire affilié » désigne une personne ou une entité qui, directe ou indirectement, à travers un ou plusieurs intermédiaires, contrôle, est contrôlée par, ou est sous contrôle commun avec, la personne ou l’entité spécifiée, et (B) le terme « contrôle » (y compris les termes « contrôlé par » et « sous contrôle commun avec ») a le même sens indiqué à l’article 2.9 (c) des présentes.
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 calendaires (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) Xx, dans les cent quatre-vingts (180) jours calendaires 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 calendaires 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 constitutifs de l’ICANN) par l’organisation de soutien aux extensions génériques (la « GNSO
») quant à la substance de tel amendement rejeté. Le processus d’élaboration 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 constitutifs 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 constitutifs 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 calendaires, 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 calendaires ; 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 »).
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.
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 calendaires 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 calendaires 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 calendaires 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 calendaires 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 calendaires 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 calendaires à 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 calendaires 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. Afin d’éviter toute confusion, 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 de l’article 7.6, 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. Afin d’éviter toute confusion, 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 : (A) un amendement de la spécification 1, (B) 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 constitutifs 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 calendaires , 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 calendaires (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 calendaires (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 calendaires à 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 calendaires à 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 principes à 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 calendaires 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 calendaires à
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 calendaires 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 calendaires. 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 constitutifs 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 calendaires 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
calendaires , 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 calendaires. 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 calendaires. 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 seront 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 Attention : Président-directeur général
Avec une copie obligatoire pour : 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 :
Courrier électronique : (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 le présent 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 Ordres é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.
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.
») 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.
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 à la sous-section (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 à la sous-section (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.
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.
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 :
1. Service DNS – Contenu de la zone TLD
Nonobstant toute autre disposition des présentes, tel qu’il est indiqué à l’article 2.2.3.3 du Guide de candidature gTLD, le contenu admissible pour le service DNS du TLD sont les suivants :
1,1. Pour la classe « Internet » (IN) :
1.1.1. Enregistrement Apex SOA.
1.1.2. Enregistrements Apex NS et colle « in-bailiwick » pour les serveurs DNS de TLD
1.1.3. Enregistrements NS et colle « in-bailiwick » pour les serveurs DNS des noms enregistrés dans le TLD.
1.1.4. Enregistrements DS pour les noms enregistrés dans le TLD.
1.1.5. Enregistrements associés à la signature de la zone TLD (c’est-à-dire XXXXX, XXXXXX, XXXX, XXXX0XXXXX et NSEC3)
1.1.6. Enregistrement Apex TXT aux fins d’identifier les versions de la zone
1.1.7. Enregistrement Apex TYPE65534 pour la signalisation de la signature automatique du DNSSEC
1,2. Pour la classe « Chaos » (CH) :
1.2.1. Enregistrements TXT pour la version du serveur / identification (par exemple, les enregistrements TXT pour “version.bind.”, “id.server.”, “authors.bind” et / ou “hostname.bind.”)
(Remarque : La langue ci-dessus ne permet absolument pas, entre autres, l’inclusion des enregistrements de ressources DNS qui permettrait l’existence d’un nom de domaine sans point (par exemple, apex A, AAAA, enregistrements MX) dans la zone TLD).
Si l’opérateur de registre souhaite placer tout type ou classe d’enregistrement de ressource
DNS dans son service DNS de TLD (autres que ceux énumérés aux articles 1.1 ou 1.2
ci-dessus), il doit décrire en détail sa proposition et soumettre une demande de Processus d’évaluation des services de registre (RSEP). Cette proposition sera évaluée par le RSEP pour déterminer si le service pourrait comporter un risque d’effet négatif important sur la sécurité ou la stabilité du DNS. L’opérateur de registre reconnaît et admet qu’un service basé sur l’utilisation d’enregistrements de ressource DNS et / ou classes peu communs dans la zone TLD, même autorisés, peut ne pas fonctionner comme prévu pour tous les utilisateurs en raison du manque de soutien apporté au logiciel.
SPECIFICATION 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 constitutifs 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 constitutifs 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.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 ou de bureau d’enregistrement ;
1.2.6 les restrictions à la propriété hybride des opérateurs de registre et
des bureaux d’enregistrement ou des revendeurs des bureaux
d’enregistrement, les règlementations et restrictions par rapport aux opérations 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 ou la spéculation sur les noms
de domaine par les registres ou les bureaux d’enregistrement ;
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 résiliation.
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.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
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 »).
pour laquelle cette politique provisoire est adoptée et mettra immédiatement en œuvre le processus d’élaboration de politiques consensuelles défini dans les statuts constitutifs 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.
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.
SPECIFICATION 2
CONDITIONS DE L’ENTIERCEMENT 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 d’entiercement de données liés au contrat de registre. Les spécifications techniques suivantes établies dans la partie A et les exigences légales établies dans la partie B seront incluses dans tout contrat d’entiercement de données 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 d’entiercement 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 l’entiercement 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 (c’est-à-dire les ajouts, modifications ou annulation de données).
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.
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 calendaires. 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 de l’entiercement 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 :
(2) Les fichiers de zone sont regroupés dans des fichiers distribués nommés
comme à (1), mais avec l’extension tar.
conformément à la norme RFC 4880. L’algorithme suggéré pour le hachage
des signatures numériques est SHA256.
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ù :
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 ;
(4) « thick-{gurid} », si les données représentent les données
d’enregistrement détaillé d’un bureau d’enregistrement spécifique, tel que défini à l’article 3.2 de la spécification 4. L’élément {gurid} doit être remplacé par l’ID du bureau d’enregistrement chez l’IANA associé aux données.
5.5. {rev} est remplacé par le nombre de révisions (ou renvois) du fichier, en commençant par 0 :
« ryde ».
6. Distribution de 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 de l’opérateur de registre (éventuellement par un message électronique authentifié) incluant une copie du rapport généré lors de la création du dépôt et stipulant que le dépôt a été inspecté par l’opérateur de registre et qu’il est complet et exact. La préparation et la présentation de cette déclaration doit être effectuée par l'opérateur de registre ou son représentant, à condition que cette personne désignée ne soit pas le dépositaire légal ou un affilié du dépositaire légal. L’opérateur de registre inclura les attributs
« id » et « resend » du dépôt dans sa déclaration. Les attributs sont expliqués dans la partie A, article 9, référence 1 de 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 calendaires 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é.
(5) Le processus de vérification étendu du dépositaire légal, tel que défini
ci-dessous dans la référence 2 de la partie A de cette spécification, ainsi que tout autre processus de vérification d’entiercement de données contenus dans ladite référence.
En cas de divergence constatée à l’une de ces étapes, le dépôt sera considéré comme
incomplet.
9. Références.
(1) Spécification de l’entiercement 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
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 calendaires 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 calendaires 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 calendaires 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 calendaires 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
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.
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.
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 calendaires 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.
SPECIFICATION 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 pour chaque bureau d’enregistrement :
Nº du cham p | Nom du champ | Description |
01 | Nom du bureau d’enregistrement | Nom de société complet enregistré auprès de l’IANA |
02 | ID IANA | 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 |
03 | total de domaines | noms de domaine totaux sous parrainage dans un statut EPP quelconque mais en pendingCreate qui n’ont pas été purgés |
04 | total des serveurs de noms | 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, pas en statut EPP pendingCreate) d’une durée initiale d’un (1) an (et non supprimés dans le 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, pas en statut EPP pendingCreate) d’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-successful | 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-nacked | 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-nodecision | 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 de la période de rapport |
35 | restored-noreport | nombre total des noms restaurés pour lesquels un rapport de restauration est requis par le registre, mais un rapport de restauration quele bureau d’enregistrement n’a pas envoyé. |
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 du fichier devra suivre le modèle
« gTLD-activity-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 :
Nº du champ | Nom du champ | Description |
01 | operational-registrars | nombre de bureaux d’enregistrement opérationnels dans le système de production à la fin de la période de rapport |
02 | zfa-passwords | nombre de mots de passe d’accès au fichier de la zone active à la fin de la période de rapport; « CZDS » peut être utilisé au lieu du nombre des mots de passe d’accès au fichier de zone, si le service centralisé de données de zone est utilisé pour fournir le fichier de zone à l’utilisateur final |
03 | whois-43-queries | nombre de requêtes WHOIS (port-43) recevant une réponse au cours de la période de rapport |
04 | 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 |
05 | searchable-whois-queries | nombre de requêtes Whois consultables recevant une réponse au cours de la période de rapport, (le cas échéant) |
06 | dns-udp-queries-received | nombre de requêtes DNS reçues par transport UDP au cours de la période de rapport |
Nº du champ | Nom du champ | Description |
07 | dns-udp-queries-responded | nombre de requêtes DNS reçues par transport UDP qui ont reçu une réponse au cours de la période de rapport |
08 | dns-tcp-queries-received | nombre de requêtes DNS reçues par transport TCP au cours de la période de rapport |
09 | dns-tcp-queries-responded | nombre de requêtes DNS reçues par transport TCP qui ont reçu une réponse au cours de la période de rapport |
10 | srs-dom-check | nombre de demandes de « contrôle » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport |
11 | srs-dom-create | nombre de demandes de « création » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport |
12 | srs-dom-delete | nombre de demandes de « suppression » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport |
13 | srs-dom-info | nombre de demandes « d’infos » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport |
14 | srs-dom-renew | nombre de demandes de « renouvellement » de nom de domaine SRS (EPP et toute autre interface) recevant une réponse au xxxxx xx xx xxxxxxx xx xxxxxxx |
00 | xxx-xxx-xxx-xxxxxxx-xxxxxx | xombre 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 |
16 | srs-dom-rgp-restore-request | 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 |
17 | srs-dom-transfer-approve | nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à approuver les transferts recevant une réponse |
Nº du champ | Nom du champ | Description |
au cours de la période de rapport | ||
18 | srs-dom-transfer-cancel | nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à annuler les transferts recevant une réponse au cours de la période de rapport |
19 | srs-dom-transfer-query | nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à faire une demande concernant un transfert recevant une réponse au cours de la période de rapport |
20 | srs-dom-transfer-reject | nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à rejeter les transferts recevant une réponse au cours de la période de rapport |
21 | srs-dom-transfer-request | nombre de demandes de « transfert » de nom de domaine SRS (EPP et toute autre interface) à demander des transferts recevant une réponse au cours de la période de rapport |
22 | srs-dom-update | nombre de demandes de « mise à jour » de nom de domaine SRS (EPP et toute autre interface) (n’incluant pas les requêtes de restauration) recevant une réponse au cours de la période de rapport |
23 | srs-host-check | 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 |
24 | 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 |
25 | 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 |
26 | 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 |
27 | 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 |
28 | srs-cont-check | nombre de requêtes de « contrôle » d’hôte de |
Nº du champ | Nom du champ | Description |
SRS (EPP et toute autre interface) recevant une réponse au cours de la période de rapport | ||
29 | 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 |
30 | 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 |
31 | 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 |
32 | srs-cont-transfer-approve | 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 |
33 | 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 |
34 | 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 |
35 | 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 période de rapport |
36 | srs-cont-transfer-request | 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 |
37 | 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.
SPECIFICATION 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.
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ête : 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 : EXEMPLE TITULAIRE DU NOM DE DOMAINE
Organisation du titulaire du nom de domaine : EXEMPLE ORGANISATION Rue du titulaire du nom de domaine : 123 EXEMPLE RUE
Ville du titulaire du nom de domaine : VILLE EXEMPLE État / province du titulaire du nom de domaine : AP Code postal du titulaire du nom de domaine : A1A1A1 Pays du titulaire du nom de domaine : EX
Pays 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 Adresse é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 : 120 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
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 : 120 XXXXXXX XXXXXX Xille du technicien : VILLE EXEMPLE Province / état 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 relatives au bureau d’enregistrement :
1.6.1 Format de requête : whois “registrar Example Registrar, Inc.”
1.6.2 Format de réponse :
Nom du bureau d’enregistrement : Example Registrar, Inc. Rue : 1200 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 E-mail: 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
E-mail : 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
E-mail : xxxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx Contact technique : Xxxx Xxxx
Numéro de téléphone : +1.3105551215 Numéro de télécopie : +1.3105551216
E-mail : 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 relatives au serveur de nom :
1.7.1 Format de requête : « serveur de noms (nom de serveur de noms) » du whois, ou « serveur de noms (adresse IP)» du whois. Par exemple :
« serveur de noms NS1.EXAMPLE.TLD ».
1.7.2 Format de réponse :
Nom de 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.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 cette section.
1.10.1 L’opérateur de registre proposera une facilité de recherche dans le
service d’annuaire basé sur le Web.
registre, c’est-à-dire aux enregistrements de type glue).
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 SFTP de fichier de zone (ou autre service pris en charge par le registre) pour une URL gérée et spécifiée par l’ICANN (spécifiquement, <TLD>.xxx.xxxxx.xxx où <TLD> est le TLD 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 SFTP 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 :
<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.
9. Pas d’utilisation du « @ » pour annoncer l’origine actuelle.
11. Pas de directive $INCLUDE.
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.
16. Un enregistrement SOA doit se trouver au début et (copié) à la fin du fichier de zone.
2.1.5 Utilisation des données par l’utilisateur. L’opérateur de registre permettra à l’utilisateur d’utiliser le fichier de zone à des fins licites ; pourvu que (a) l’utilisateur prenne toutes les mesures raisonnables pour protéger les données de tout accès non autorisé et, utilisation et divulgation, et (b) l’opérateur de registre ne sera tenu ou autorisé,
dans aucun cas, à permettre à l’utilisateur d’utiliser les données pour,
(i) permettre, autoriser, ou autrement soutenir lesaucune activité de marketing d’entités autres que les clients existants de l’utilisateur, indépendamment du moyen utilisé (ces moyens comprennent, sans s’y limiter, la transmission par emaile-mail, téléphone ou fax, courrier postal, SMS et alertes à la radio de publicités ou annonces commerciales massives non demandées à des entités), (ii) habiliter des processus électroniques automatisés à grand volume qui envoient des requêtes ou des données aux systèmes de l’opérateur de registre ou d’un bureau d’enregistrement quelconque accrédité par l’ICANN, ou (iii) interrompre, altérer ou interférer dans l’opération commerciale habituelle de tout titulaire de nom de domaine.
2.1.6 Période d’utilisation. L’opérateur de registre, par l’intermédiaire du fournisseur CZDA, s’engage à fournir à chaque utilisateur un accès au fichier de zone durant une période minimale de trois (3) mois.
L’opérateur de registre autorisera les utilisateurs à renouveler leur octroi d’accès.
2.1.7 Accès fourni sans paiement de droits. L’opérateur de registre s’engage à fournir à l’utilisateur un accès gratuit au fichier de zone et le fournisseur CZDA s’engage à faciliter cet accès.
2.2. 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
(xxxx), 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 du bureau d’enregistrement (roid ID IANA) , 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 de l’entiercement de données (y compris le chiffrement, la signature, etc.) mais en incluant uniquement les champs mentionnés au paragraphe précédent. Autrement dit, le fichier contiendra uniquement les objets domaine et bureau d’enregistrement ainsi que les champs mentionnés ci-dessus.
L’opérateur de registre a la possibilité de fournir 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 de
l’entiercement 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 calendaires 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.
SPECIFICATION 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ées 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.
dans le cadre de l’exploitation du registre pour le TLD : WWW, RDDS et WHOIS. L’étiquette ASCII suivante doit être attribuée à l’opérateur de
registre suite à la délégation dans la zone racine à tous les niveaux pour une utilisation dans le cadre de l’exploitation du registre pour le TLD : NIC. L’opérateur de registre peut activer le WWW, le RDDS et le WHOIS dans le DNS, mais doit activer le NIC dans le DNS, car il est nécessaire pour le fonctionnement du TLD (conformément aux dispositions de la pièce A, le NIC d’étiquette ASCII doit être fourni dans le DNS comme une section de zone dans les enregistrement de ressource NS). 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 est 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. Ces domaines devront être identifiés par l’ID de bureau d’enregistrement 9999.
pourra également activer la traduction linguistique spécifique ou la translittération du terme « NIC » ou une abréviation de la traduction du terme « Centre d’information de réseaux » dans le DNS
conformément aux tableaux IDN et aux règles d’enregistrement d’IDN de l’opérateur de registre. Une telle traduction, translittération ou abréviation pourront être réservées par l’opérateur de registre et utilisées en plus de l’étiquette du NIC pour fournir toutes les fonctions de registre nécessaires. Pour éviter tout doute, l’opérateur de registre est tenu d’activer l’étiquette du NIC en ASCII conformément à l’article
3.1 de la présente spécification 3.
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é). Si l’opérateur de registre choisit l’option (ii) ci-dessus, il devra identifier ces transactions à l’aide de
l’ID de bureau d’enregistrement 9998. À la discrétion de l’opérateur de registre et dans le respect de toutes les autres dispositions du présent contrat, y compris les RPM spécifiés dans la spécification 7, ces noms peuvent être libérés et enregistrés au nom d’une autre personne ou entité.
é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 ils peuvent être libérés pour leur enregistrement à l’opérateur de registre ou à toute autre personne ou entité à la discrétion de l’opérateur de registre, sous réserve de conformité avec toutes les dispositions du présent contrat, y compris les RPM applicables spécifiées à la spécification 7. 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 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.
présente spécification 5, et (iii) ne nuira pas à la qualification de l’opérateur de registre comme un TLD de marque conformément à la spécification 13 (dispositions relatives aux TLD de marques) ci-après (le cas échéant).
4. Noms de pays et de territoires. Les noms de pays et de territoires (y compris leurs variantes IDN, le cas échéant) contenus dans les listes internationalement reconnues suivantes seront exclus de l’enregistrement ou affectés à l’opérateur de registre à tous les niveaux :
<xxxx://xxx.xxx.xxx/xxx/xxxxxxx/xxxxxxx_xxxxx/xxx_0000_xxxx_xxxxx/xxx-0 166-1_decoding_table.htm> ;
à 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 registre 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 calendaires 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 identificateurs 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 calendaires 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 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 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.
SPECIFICATION 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, 3226, 3596, 4343, 5966 et 6891. 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 (RGP), celle-ci respectera la norme RFC 3915 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 »). Pour éviter tout doute, l'opérateur de registre devra signer le fichier de zone de <TLD> et les fichiers de zone utilisés comme colle
« in-bailiwick » pour les serveurs DNS du TLD. Pendant la durée du contrat, l’opérateur de registre s’engage à respecter les RFC 4033, 4034, 4035, 4509 et suivantes, et à se conformer aux meilleures pratiques décrites dans la RFC 6781 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 des 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. La validation DNSSEC doit être active et utiliser l’ensemble de clé de signature de clé de la racine DNS de l’IANA (disponible à xxxxx://xxx.xxxx.xxx/xxxxxx/xxxxx) comme une ancre de confiance pour les services de registre de l’opérateur de registre qui utilisent les données obtenues par le biais de réponses DNS.
1.4. IDN. Si l’opérateur de registre propose des noms de domaine internationalisés (« IDN »), 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.
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.
1.6. Base de données de la zone racine de l’IANA. Afin d’assurer que les informations faisant autorité sur le TLD restent accessibles au public, l’opérateur de registre devra présenter une demande de modification à l’opérateur des fonctions IANA pour mettre à jour les enregistrements DNS ou WHOIS n’étant pas à jour ou étant inexacts pour le TLD. L’opérateur de registre devra déployer des efforts commercialement raisonnables pour soumettre une telle demande de modification au plus tard sept (7) jours calendaires suivant la date à laquelle les enregistrements WHOIS ou DNS deviennent obsolètes ou inexacts. L’opérateur de registre devra soumettre
toutes les demandes de modification conformément aux procédures prévues à <xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx>.
1.7. Filtre d’entrées au réseau. L’opérateur de registre devra mettre en œuvre des contrôles de filtrage d’entrées au réseau pour ses services de registre tel que décrit aux BCP 38 et BCP 84, que l’ICANN mettra également en œuvre.
2. Services de registre
2.1. Services de registre. Les « services de registre » sont, 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 ou pour lesquels le titulaire de nom de domaine 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 reçoivent des requêtes, les serveurs de noms publics faisant autorité doivent renvoyer une réponse « erreur de nom » (également appelée XXXXXXXX), RCODE 3, telle que décrite dans le RFC 1035 et dans les RFC associés. 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 mise à jour ou perçoit des revenus sur cette mise à jour.
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. Afin d’éviter toute confusion, 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. Afin d’éviter toute confusion, 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 la 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 calendaires 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
alternative à l’activation de noms et (B) l’opérateur de registre bloque tous les noms de domaine de second niveau identifiés par l’ICANN et é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.
recherche et d’analyse des opérations du DNS,
(DNS-OARC)<xxxxx://xxx.xxx-xxxx.xxx/xxxx/xxxx/xxxx>.
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 d’administration de l’ICANN le 7 octobre 2013, qui est disponible à
<xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxxxxxx/xxxxxxxxxxx-x ew-gtld-annex-1-07oct13-en.pdf>.
6.3. Gestion du rapport de collision de noms
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.
SPECIFICATION 7
EXIGENCES MINIMALES S’APPLIQUANT AUX MÉCANISMES DE PROTECTION DES DROITS
1. Mécanismes de protection des droits. L’opérateur de registre 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 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ée xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxx-xxxxxxxxxxxx (les « exigences du centre 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 bureau central de marques de commerce 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. L’opérateur de registre devra conclure un contrat de registre - bureau d’enregistrement contraignant et exécutoire avec au moins un bureau d’enregistrement accrédité par l’ICANN pour autoriser ce(s) bureau(x) d’enregistrement à enregistrer des noms de domaine dans le TLD comme suit :
d’information sur les marques), l’opérateur de registre doit conclure un contrat de registre-bureau d’enregistrement contraignant et exécutoire avec au moins un bureau d’enregistrement accrédité par l’ICANN avant
l’attribution des noms de domaine en vertu de ce programme de lancement qualifié ou programme de lancement approuvé, selon le cas ;
registre-bureau d’enregistrement contraignant et exécutoire avec au moins un bureau d’enregistrement accrédité par l’ICANN au moins trente (30) jours calendaires avant la date d’échéance de la période d’enregistrement
prioritaire (tel que défini dans les exigences du Centre d’échange d’information sur les marques) pour le TLD ; ou
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 à la section 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 uniforme de suspension rapide (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.
SPECIFICATION 8
INSTRUMENT D’OPÉRATIONS CONTINUES.
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 calendaires 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).
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.
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.
SPECIFICATION 9
CODE DE CONDUITE DE L’OPÉRATEUR DE REGISTRE
services de registre à l’égard du TLD (désignés par « tiers associé au registre »), à :
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 ;
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 calendaires suivant la fin de chaque année calendaire, 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.
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.
SPECIFICATION 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 | |
Période 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 du « 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