Skip to main content
Resources

Résolutions du Conseil d’administration adoptées | Réunion ordinaire du Conseil d’administration de l’ICANN

Cette page est disponible en:

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal de la réunion du Conseil d’administration
    2. Nomination d’un nouveau membre du SSAC
    3. Approbation des modifications à la charte de l’unité constitutive des utilisateurs commerciaux (BC) de la GNSO
    4. Conclusion du contrat pour le lieu de la réunion de l’ICANN de mars 2019
    5. Conclusion du contrat pour le lieu de la réunion de l’ICANN de novembre 2019.
    6. Délégation au National Internet Exchange of India (NIXI) de huit noms de domaine internationalisés représentant l’Inde
    7. Représentant du bureau de liaison d’Istanbul
    8. Directeur de la filiale de Bruxelles et représentant légal
    9. Remerciements à l’attention de l’hôte de la réunion ICANN 59
    10. Remerciements à l’attention du sponsor de la réunion ICANN 59
    11. Remerciements à l’attention des interprètes, du personnel, des organisateurs et des équipes de l’hôtel ayant contribué à la réunion ICANN 59
  2. Ordre du jour principal :
    1. Approbation du plan opérationnel et budget pour l’exercice fiscal 2018, du budget de l’IANA et de la mise à jour du plan opérationnel quinquennal pour le même exercice fiscal
    2. Considération des recommandations du SSAC sur le registre des avis du Conseil d’administration : SAC062, SAC063, SAC064, SAC065, SAC070 et SAC073
    3. Considération de la recommandation révisée du Comité de gouvernance du Conseil d’administration sur les demandes de réexamen 13-16 et 14-10
    4. Considération de la recommandation du BGC relative à la demande de réexamen 17-1
    5. Renouvèlement du contrat de registre de .NET

 

  1. Ordre du jour approuvé :

    1. Approbation du procès-verbal de la réunion du Conseil d’administration

      Il est résolu (2017.06.24.01) que le Conseil d’administration approuve le procès-verbal de la réunion ordinaire du Conseil d’administration de l’ICANN du 18 mai 2017.

    2. Nomination d’un nouveau membre du SSAC

      Attendu que, le Comité consultatif sur la sécurité et la stabilité (SSAC) procède à l’évaluation de ses membres et à des ajustements le cas échéant.

      Attendu que, le Comité des membres du SSAC, pour le compte du SSAC, demande au Conseil d’administration de nommer Andrew de la Haije au SSAC pour un mandat de trois ans, qui deviendra effectif immédiatement après son approbation par le Conseil d’administration et prendra fin le 31 décembre 2020.

      Il est résolu (2017.06.24.02) que le Conseil d’administration nomme Andrew de la Haije au SSAC pour un mandat de trois ans qui deviendra effectif immédiatement après son approbation par le Conseil d’administration et prendra fin le 31 décembre 2020.

      Fondements de la résolution 2017.06.24.02

      Le SSAC est un groupe diversifié composé de personnes dont l’expertise dans des sujets spécifiques lui permet de satisfaire aux objectifs de sa charte et de remplir sa mission. Depuis sa création, le SSAC a invité des personnes ayant une connaissance et une expérience approfondies dans les domaines techniques et de sécurité fondamentaux pour la sécurité et la stabilité des systèmes de nommage et d’adressage d’Internet.

      Le fonctionnement continu du SSAC en tant qu’organe compétent dépend de l’ensemble des experts dans des domaines donnés qui consentent à consacrer une partie de leur temps et de leur énergie pour mener à bien la mission du SSAC. Andrew est le directeur d’exploitation des réseaux IP européens (RIPE), un poste qu’il occupe depuis plus de 10 ans. Il a participé activement au Groupe de travail de génie Internet (IETF) et à l’ICANN à divers titres pendant de nombreuses années. Il apporte une expérience opérationnelle significative de la communauté des Registres Internet régionaux (RIR), notamment une expertise technique considérable. Le SSAC estime qu’Andrew a beaucoup à lui apporter.

    3. Approbation des modifications à la charte de l’unité constitutive des utilisateurs commerciaux (BC) de la GNSO

      Attendu que, les statuts constitutifs de l’ICANN (chapitre XI, article 11.5(c)) établissent que « chaque groupe de parties prenantes [de la GNSO]… sera reconnu par le Conseil d’administration de l’ICANN ».

      Attendu que, le Conseil d’administration a mis en place un processus d’amendement des chartes des groupes de parties prenantes et des unités constitutives de la GNSO (ci-après le « Processus »).

      Attendu que, l’Unité constitutive des utilisateurs commerciaux de la GNSO (BC), l’organisation ICANN et le Comité du Conseil d’administration chargé de l’efficacité organisationnelle (OEC) ont complété à ce jour toutes les étapes identifiées dans le Processus - y compris une décision disant que ces modifications n’auraient aucune conséquence en matière de fiscalité ou de responsabilité pour l’organisation ICANN.

      Il est résolu (2017.06.24.03) que le Conseil d’administration de l’ICANN approuve les amendements à la charte de la BC. Le Président-directeur général ou son représentant est tenu de communiquer cette résolution aux dirigeants de la BC. La BC et l’organisation ICANN devront fournir l’accès au nouveau document constitutif sur les pages Web appropriées de l’ICANN et de la BC.

      Fondements de la résolution 2017.06.24.03

      Pourquoi le Conseil d’administration aborde-t-il cette question maintenant ?

      Conformément aux statuts constitutifs de l’ICANN (chapitre XI, article 11.5(c)), « Chaque groupe de parties prenantes… sera reconnu par le Conseil d’administration de l’ICANN ». Pour le Conseil d’administration, ce libellé signifie qu’il est tenu d’approuver formellement toutes les modifications apportées aux documents constitutifs des groupes de représentants et/ou des unités constitutives de la GNSO.

      En septembre 2013, le Conseil d’administration a mis au point un processus d’amendement des chartes des groupes de représentants et des unités constitutives de la GNSO (le « processus ») afin de fournir une méthodologie simplifiée pour rester en conformité avec les exigences des statuts.

      Plus tôt cette année, l’Unité constitutive des utilisateurs commerciaux a approuvé la version modifiée de ses documents constitutifs et a bénéficié du Processus.

      Quelles sont les propositions à l’étude ?

      L’Unité constitutive des utilisateurs commerciaux a modifié sa charte pour l’adapter à l’évolution de sa composition et de gérer plus efficacement ses responsabilités en matière d’élaboration de politiques. Parmi les différentes modifications apportées à la charte, les plus significatives sont les suivantes :

      1. création d’un nouveau poste de conseiller juridique (GC) dans le cadre du comité exécutif de la BC (BC-EC). Conformément à la nouvelle charte, le conseiller juridique ne détient pas le droit de vote au sein du BC-EC et le rôle principal du nouveau conseiller juridique semble s’articuler autour du maintien d’une entité BC récemment incorporée ;
      2. ajout de nouvelles dispositions reconnaissant le rôle que l’ombudsman de l’ICANN pourrait jouer dans la résolution de plaintes éventuelles présentées par les membres de la BC concernant des actions ou des activités au sein de l’unité constitutive. Ces dispositions semblent confirmer la capacité des membres à avoir recours à l’ombudsman comme moyen d’appel des actions de la BC avec lesquelles ils sont en désaccord ; et
      3. révision des critères du seuil d’admissibilité de l’Unité constitutive des utilisateurs commerciaux. En particulier, dans le but d’éviter ce que la charte considère des « conflits d’intérêts », la charte révisée n’admet pas l’adhésion des entités qui obtiennent plus de 30 % de leur chiffre d’affaires annuel comme opérateur de registre, bureau d’enregistrement ou revendeur de noms de domaine (par exemple, les « Parties contractantes »).

      Quelles parties prenantes ou autres ont été consultées ?

      Outre les discussions communautaires exhaustives menées au sein de la BC, les modifications proposées ont fait l’objet d’une période de consultation publique de 41 jours (6 janvier au 15 février 2017). À l’issue de cette période, le 8 mars 2017, le personnel a rédigé un rapport de synthèse soumis à l’examen de la communauté et du Conseil d’administration.

      Quels sont les principaux documents examinés par le Conseil ?

      Les membres du Conseil d’administration ont examiné les modifications proposées à la charte, une copie du rapport de synthèse du personnel résumant les commentaires de la communauté et une liste de suivi de problèmes qui décrit la dispense de divers commentaires de la communauté considérés par l’Unité constitutive des utilisateurs commerciaux.

      Quels sont les facteurs que le Conseil a trouvés significatifs ?

      L’Unité constitutive des utilisateurs commerciaux de la GNSO, l’organisation ICANN et le Comité du Conseil d’administration chargé de l’efficacité opérationnelle ont suivi toutes les étapes du processus et ont notamment précisé que les propositions de modifications de la charte n’auront aucune répercussion financière ou en termes de responsabilité sur l’organisation ICANN et publié les modifications pour obtenir les commentaires et la révision de la communauté.

      Y a-t-il des effets positifs ou négatifs pour la communauté ?

      La NCUC a modifié sa charte afin de s’adapter à l’évolution de sa composition et de gérer plus efficacement ses responsabilités en matière d’élaboration de politiques.

      Y a-t-il des répercussions financières sur l’ICANN (Plan stratégique, Plan opérationnel, budget), sur la communauté et/ou sur le grand public ?

      Les modifications comprennent les ajustements aux seuils d’admissibilité établis par la BC pour l’adhésion à l’unité constitutive pouvant affecter les membres individuels de la communauté.

      Existe-t-il des problèmes de sécurité, stabilité et résilience liés au DNS ?

      Cette décision ne devrait avoir aucun impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

      S’agit-il d’un processus d’élaboration de politiques défini au sein des organisations de soutien de l’ICANN ou d’une fonction organisationnelle administrative de l’ICANN nécessitant ou non une consultation publique ?

      Les modifications proposées ont fait l’objet d’une période de consultation publique de 41 jours (du 6 janvier au 15 février 2017).

    4. Conclusion du contrat pour le lieu de la réunion de l’ICANN de mars 2019

      Attendu que, l’ICANN souhaite organiser sa première réunion publique de 2019 dans la région Asie-Pacifique.

      Attendu que, le personnel a examiné avec attention tous les lieux proposés pour tenir sa réunion dans la région Asie-Pacifique et estime que le lieu le plus approprié serait Kobe (Japon).

      Il est résolu (2017.06.24.04) que le Conseil d’administration autorise le Président-directeur général, ou son ou ses représentants, à gérer tous les aspects indispensables liés aux contrats et aux déboursements pour le centre de convention de la réunion publique de l’ICANN de mars 2019 à Kobe, Japon, jusqu’à concurrence de [À REMPLIR APRÈS NÉGOCIATIONS].

      Il est résolu (2017.06.24.07) que les éléments spécifiques de cette résolution restent confidentiels à des fins de négociation, conformément au chapitre III, article 3.5b des statuts constitutifs de l’ICANN, jusqu’à ce que le Président-directeur général en autorise la divulgation.

      Fondements des résolutions 2017.06.24.04 à 2017.06.24.05

      Dans le cadre de son calendrier de réunions publiques, l’ICANN organise actuellement trois réunions par an dans des régions géographiques différentes (tel que décrit dans ses statuts constitutifs). La réunion ICANN 64, prévue du 9 au 14 mars 2019, aura lieu dans la région Asie-Pacifique. Un appel à recommandations concernant le lieu de la réunion en Amérique du Nord a été publié le 15 juillet 2016. L’ICANN a reçu de nombreuses propositions

      que le personnel a examinées avec attention, de même que d’autres endroits. Il a ensuite rédigé un document afin de déterminer quels sites remplissaient les Critères de sélection du lieu de réunion (http://meetings.icann.org/location-selection-criteria). Sur la base des propositions et de cet examen, l’ICANN a décidé que la réunion ICANN 64 aurait lieu à Kobe (Japon).

      Le Conseil d’administration a examiné la présentation du personnel quant au lieu de la réunion publique de l’ICANN de mars 2019, à Kobe (Japon), le respect des principales conditions établies dans les critères de sélection du lieu de réunion ainsi que les couts liés au lieu choisi.

      Les frais d’organisation de la réunion auront un impact financier sur l’ICANN, ainsi que sur la communauté, car cela implique des frais de voyage pour se déplacer jusqu’à l’emplacement de la réunion. Cet impact est à prévoir indépendamment de l’emplacement de la réunion. Cette décision n’aura aucune incidence sur la sécurité ou la stabilité du DNS.

      Le Conseil d’administration remercie tous ceux qui ont recommandé des sites pour la réunion ICANN 64.

      Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    5. Conclusion du contrat pour le lieu de la réunion de l’ICANN de novembre 2019.

      Attendu que, l’ICANN souhaite organiser sa troisième réunion publique de 2019 dans la région de l’Amérique du nord.

      Attendu que, le personnel a examiné avec attention tous les lieux proposés pour tenir sa réunion en Amérique du Nord et estime que le lieu le plus approprié serait Montréal (Canada).

      Il est résolu (2017.06.24.06) que le Conseil d’administration autorise le Président-directeur général, ou son ou ses représentants, à gérer tous les aspects indispensables liés aux contrats et aux déboursements pour le centre de convention de la réunion publique de l’ICANN de novembre 2019 à Montréal, Canada, jusqu’à concurrence de [À REMPLIR APRÈS NÉGOCIATIONS].

      Il est résolu (2017.06.24.07) que les éléments spécifiques de cette résolution restent confidentiels à des fins de négociation, conformément au chapitre III, article 3.5b des statuts constitutifs de l’ICANN, jusqu’à ce que le Président-directeur général en autorise la divulgation.

      Fondements des résolutions 2017.06.24.06 à 2017.06.24.07

      Dans le cadre de son calendrier de réunions publiques, l’ICANN organise actuellement trois réunions par an dans des régions géographiques différentes (tel que décrit dans ses statuts constitutifs). La réunion ICANN 66, prévue du 2 au 8 novembre 2019, aura lieu dans la région géographique Amérique du Nord. Un appel à recommandations concernant le lieu de la réunion en Amérique du Nord a été publié le 15 juillet 2016. L’ICANN a reçu de nombreuses propositions

      que le personnel a examinées avec attention, de même que d’autres endroits. Il a ensuite rédigé un document afin de déterminer quels sites remplissaient les Critères de sélection du lieu de réunion (http://meetings.icann.org/location-selection-criteria). Sur la base des propositions et de cet examen, l’ICANN a décidé que la réunion ICANN 66 aurait lieu à Montréal (Canada).

      Le Conseil d’administration a examiné la présentation du personnel quant au lieu de la réunion publique de l’ICANN de novembre 2019, à Montréal (Canada), le respect des principales conditions établies dans les critères de sélection du lieu de réunion ainsi que les couts liés au lieu choisi.

      Les frais d’organisation de la réunion auront un impact financier sur l’ICANN, ainsi que sur la communauté, car cela implique des frais de voyage pour se déplacer jusqu’à l’emplacement de la réunion. Cet impact est à prévoir indépendamment de l’emplacement de la réunion. Cette décision n’aura aucune incidence sur la sécurité ou la stabilité du DNS.

      Le Conseil d’administration remercie tous ceux qui ont recommandé des sites pour la réunion ICANN 66.

      Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    6. Délégation au National Internet Exchange of India (NIXI) de huit noms de domaine internationalisés représentant l’Inde

      Il est résolu (2017.06.24.08) que, dans le cadre de l’exercice de ses responsabilités en vertu du contrat des fonctions IANA relatives au nommage avec l’ICANN, les Identificateurs techniques publics (PTI) ont examiné et évalué la demande de délégation des huit domaines de premier niveau géographique (.ಭಾರತ, .ഭാരതം, .ভাৰত, .ଭାରତ, .بارت, .भारतम्, .भारोत, .ڀارت) représentant l’Inde en plusieurs langues présentée par le National Internet Exchange of India. La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Fondements de la résolution 2017.06.24.08

      Pourquoi le Conseil aborde-t-il cette question maintenant ?

      Conformément au contrat des fonctions IANA relatives au nommage, les Identificateurs techniques publics (PTI) ont évalué la demande de délégation du ccTLD et présentent leur rapport au Conseil d’administration pour révision. Cet examen par le Conseil d’administration est destiné à s’assurer que les procédures correctes ont été suivies.

      Quelle est la proposition à l’étude ?

      Il est proposé d’approuver une demande visant à créer huit domaines de premier niveau géographique (.ಭಾರತ, .ഭാരതം, .ভাৰত, .ଭାରତ, .بارت , .भारतम्, .भारोत, .ڀارت) qui représentent l’Inde en plusieurs langues et d’assigner le rôle de gestionnaire au National Internet Exchange of India.

      Quelles parties prenantes (ou autres) ont été consultées ?

      Lors de l’évaluation de cette demande de délégation, la PTI a consulté le candidat et d’autres parties intéressées. Dans le cadre du processus de candidature, le candidat doit expliquer quelles consultations ont été effectuées dans le pays au sujet du ccTLD en question et dans quelle mesure celles-ci s'appliquent à la communauté internet locale.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      La PTI n’a pas connaissance de questions ou inquiétudes soulevées par la communauté concernant cette demande.

      Quels sont les principaux documents examinés par le Conseil ?

      Le Conseil d’administration a examiné les évaluations suivantes :

      • les domaines peuvent faire l’objet d’une délégation puisqu’il s’agit de chaines approuvées par le biais de la procédure accélérée pour les ccTLD IDN et représentant un pays inclus dans la norme ISO 3166-1 ;
      • le gouvernement concerné a été consulté et ne présente pas d’objections ;
      • le gestionnaire proposé et ses agents acceptent leurs responsabilités quant à la gestion de ces domaines ;
      • la proposition a démontré que la communauté Internet locale concernée a été dument consultée et apporte son soutien ;
      • la proposition n’enfreint aucune loi ou réglementation connue ;
      • la proposition garantit que les domaines seront gérés dans le pays et respecteront le droit local  ;
      • le gestionnaire proposé a confirmé qu’il assurerait la gestion des domaines de façon juste et équitable ;
      • le gestionnaire proposé a prouvé qu’il disposait de compétences opérationnelles et techniques adéquates, et qu’il a l’intention d’exploiter les domaines ;
      • la configuration technique proposée respecte les différentes exigences en matière de conformité technique ;
      • aucun risque ou doute spécifique liés à la stabilité d’Internet n’a été identifié ; et
      • le personnel recommande la mise en œuvre de cette demande sur la base des facteurs pris en compte.

      Ces évaluations sont adaptées aux critères et cadres politiques appropriés tels que la « Structure et délégation du système des noms de domaine » (RFC 1591) et les « Principes et lignes directrices du GAC pour la délégation et l’administration des domaines de premier niveau géographique ».

      Dans le cadre du processus, les rapports sur la délégation et le transfert sont publiés sur http://www.iana.org/reports.

      Quels sont les facteurs que le Conseil a trouvés significatifs ?

      Le Conseil d’administration n’a identifié aucun facteur d’inquiétude concernant cette demande.

      Y a-t-il des effets positifs ou négatifs pour la communauté ?

      L’approbation en temps voulu des gestionnaires de noms de domaine géographiques répondant aux critères d’intérêt public a un effet positif sur la mission de l’ICANN et les communautés locales auxquelles des domaines de premier niveau géographiques sont attribués. Elle correspond aux obligations de l’ICANN en vertu du contrat des fonctions IANA relatives au nommage.

      Y a-t-il des répercussions financières sur l’ICANN (plan stratégique, plan opérationnel, budget), la communauté et/ou le public ?

      La gestion des délégations des extensions géographiques dans la zone racine du DNS fait partie des fonctions IANA et le processus de délégation ne devrait pas avoir de répercussion majeure sur les dépenses prévues. L’ICANN n’a pas pour rôle d’évaluer les répercussions financières des activités relatives aux ccTLD dans un pays.

      Y a-t-il des implications pour la sécurité, la stabilité ou la résilience du DNS ?

      L’ICANN estime que cette demande ne représente aucun risque significatif pour la sécurité, la stabilité ou la résilience du DNS.

      Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    7. Représentant du bureau de liaison d’Istanbul

      Attendu que la Société pour l’attribution des noms de domaine et des numéros sur Internet, une société d’utilité publique à but non lucratif dument constituée et existant sous les lois de l’État de Californie et des États-Unis d’Amérique, dont le siège principal est situé à 12025 E. Waterfront Drive, Suite 300, Los Angeles, en Californie, USA 90094 (ICANN), a décidé d’établir un bureau de liaison (« Bureau de liaison ») à Istanbul (Turquie).

      Attendu que, par la résolution 2013.04.11.03, le Conseil d’administration de l’ICANN a nommé David Olive comme représentant du Bureau de liaison, ayant l’autorité nécessaire pour agir au nom du Bureau de liaison.

      Attendu que, le rôle de M. Olive comme représentant du Bureau de liaison prendra fin le 31 aout 2017.

      Il est résolu (2017.06.24.09) qu’à compter du 31 aout 2017, David Olive soit relevé de ses fonctions comme représentant autorisé du bureau de liaison de l’ICANN à Istanbul, en Turquie, à toutes fins.

      Il est résolu (2017.06.24.10), qu’à compter du 1er septembre 2017, Nicholas Tomasso, [INFORMATION PERSONNELLE DE CONTACT SUPPRIMÉE] soit désigné comme représentant du bureau de liaison sis à Istanbul, en Turquie, étant autorisé à agir individuellement au nom de l’ICANN dans le cadre des activités du bureau de liaison.

      Il est résolu (2017.06.24.11) que cette résolution reste confidentielle comme une « action liée au personnel ou aux questions concernant l’emploi », suivant le chapitre III, article 3.5b des statuts constitutifs de l’ICANN, en attendant l’annonce publique de la sélection du représentant du bureau de liaison d’Istanbul.

      Fondements des résolutions 2017.06.24.09 à 2017.06.24.11

      L’ICANN s’engage à poursuivre sa portée et sa présence à l’échelle internationale dans tous les fuseaux horaires du monde entier. Un des premiers aspects clés des efforts d’internationalisation de l’ICANN a été d’établir des bureaux en Turquie et à Singapour.

      L’ICANN a enregistré officiellement un bureau de liaison à Istanbul (Turquie), le 18 juin 2013. Afin que ce bureau de liaison soit convenablement organisé en Turquie, le Conseil d’administration doit désigner un représentant du Bureau de liaison. À cette fin, le Conseil a initialement désigné David Olive comme le premier représentant de liaison de l’ICANN pour aider l’ICANN à établir le bureau de liaison à Istanbul et un mandat de deux ans lui a été accordé. M. Olive a par la suite prolongé son séjour pour deux années supplémentaires. L’ICANN tient à remercier M. Olive pour ses nombreux efforts dans le but de construire un bureau stable et réussi.

      Comme M. Olive a été désigné dans un autre bureau de l’ICANN, le Conseil d’administration doit nommer un nouveau représentant. Nicholas Tomasso a accepté de s’installer à Istanbul pour devenir le nouveau représentant désigné du Bureau de liaison.

      C’est la première fois que le représentant légal du bureau de liaison a été changé. L’identification et la désignation d’un nouveau représentant montrent l’engagement des organisations de l’ICANN envers la mondialisation.

      Il n’y aura d’incidence fiscale sur l’ICANN que dans la mesure des couts de déplacement et d’autres dépenses connexes, mais cet impact a été pris en compte dans le budget pour l’exercice fiscal 2018. Cette résolution ne devrait pas avoir d’impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

      Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    8. Directeur de la filiale de Bruxelles et représentant légal

      Attendu que, la Société pour l’attribution des noms de domaine et des numéros sur Internet, une société d’utilité publique à but non lucratif dument constituée et existant sous les lois de l’État de Californie et des États-Unis d’Amérique, dont le siège principal est situé à 12025 E. Waterfront Drive, Suite 300, Los Angeles, en Californie, USA 90094 (« ICANN »), a établi une succursale d’une entité étrangère à but non lucratif en Belgique, actuellement sise à 6 Rondpoint Schuman, b. 5, 1040 Bruxelles sous le nom de Société pour l’attribution des noms de domaine et des numéros sur Internet.

      Attendu que, en vertu de la résolution 05.79 du Conseil d’administration de l’ICANN, Olof Nordling, [INFORMATION PERSONNELLE DE CONTACT SUPPRIMÉE] a été nommé directeur de la succursale et représentant légal en Belgique pour servir à ce titre jusqu’à ce que sa nomination soit retirée par résolution de ce Conseil d’administration.

      Attendu que, le rôle d’Olof Nordling comme directeur et représentant légal en Belgique prendra fin le 31 juillet 2017 à l’occasion de sa retraite de la société.

      Attendu que, à compter du 1er aout 2017, Jean-Jacques Sahel, [INFORMATION PERSONNELLE DE CONTACT SUPPRIMÉE] assumera les fonctions de directeur et représentant légal en Belgique.

      Il est résolu (2017.06.24.12), que l’autorité octroyée à Olof Nordling d’agir en tant que directeur et représentant légal de la filiale de l’ICANN à Bruxelles soit annulée à partir du 31 juillet 2017.

      Il est résolu (2017.06.24.13) que Jean-Jacques Sahel occupe le poste de nouveau directeur et représentant légal de la filiale de l’ICANN sise à Bruxelles (Belgique) à compter du 1er aout 2017 et que M. Sahel ne soit pas rémunéré pour ses services.

      Il est résolu (2017.06.24.14) que Jean-Jacques Sahel détienne le plein pouvoir pour effectuer la gestion quotidienne du bureau de l’ICANN sis à Bruxelles, Belgique, y compris sans s’y limiter les pouvoirs spécifiques suivants concernant le fonctionnement de cette filiale :

      1. représenter la société auprès de toutes les autorités publiques gouvernementales, régionales, provinciales, municipales ou autres, les tribunaux de commerce, la Banque Carrefour des entreprises, les autorités de règlementation des entreprises, les autorités fiscales, y compris l’administration de la T.V.A., le service de chèques postaux, la douane, la poste, les services téléphoniques et télégraphiques et tous les autres services et autorités publics ;
      2. signer la correspondance quotidienne, recevoir et signer les reçus pour des lettres ou colis envoyés à la société à travers la poste, la douane, les services de chemin de fer, aériens et toute autre société de transports et services ;
      3. souscrire, signer, transférer ou annuler toutes les polices d’assurance et tous les contrats de fourniture d’eau, gaz, électricité, téléphone et d’autres pour la filiale et payer des factures, des notes, et d’autres cotisations qui s’y rapportent ;
      4. signer et accepter tous les devis, contrats et ordres d’achat ou de vente de matériel de bureau et d’autres biens d’investissement, les services et les fournitures nécessaires au fonctionnement de la filiale qui n’obligent pas la société à dépenser plus de 500 € ;
      5. prendre ou consentir des baux, y compris les baux à long terme, sur l’immobilier, le matériel ou d’autres actifs immobilisés et conclure des accords dans le même but, avec l’approbation du Président-directeur général de l’ICANN ou du Conseil d’administration de l’ICANN ;
      6. demander, collecter et recevoir des sommes d’argent, des documents ou des biens de toute nature et signer les reçus y afférents ;
      7. associer la filiale à toutes les organisations professionnelles ou d’affaires ;
      8. représenter la filiale dans les procédures judiciaires ou d’arbitrage, comme demandeur ou défendeur, prendre toutes les mesures nécessaires concernant les procédures ci-dessus, obtenir tous les jugements et les exécuter ;
      9. rédiger tous les documents et les signer afin d’être en mesure d’exercer les pouvoirs énumérés ci-dessus ;
      10. adopter toutes les mesures nécessaires pour mettre en œuvre les résolutions et recommandations du Conseil d’administration ;
      11. déplacer le siège de la filiale en Belgique suite à l’approbation du Président-directeur général ou du Conseil d’administration de l’ICANN.

      Il est résolu (2017.06.24.15) que cette résolution reste confidentielle comme une « action liée au personnel ou aux questions concernant l’emploi », suivant le chapitre III, article 3.5b des statuts constitutifs de l’ICANN, en attendant l’annonce publique de la sélection du directeur et représentant légal de la filiale de Bruxelles.

      Fondements des résolutions 2017.06.24.12 à 2017.06.24.15

      L’ICANN s’engage à poursuivre sa portée et sa présence à l’échelle internationale dans tous les fuseaux horaires du monde entier. À cette fin, le Conseil d’administration de l’ICANN a adopté des résolutions pour créer une succursale en Belgique et, en 2005, a nommé Olof Nordling comme directeur et représentant légal en lui octroyant les pouvoirs nécessaires pour remplir ces fonctions. M. Nordling prendra la retraite de son emploi avec l’ICANN le 31 juillet 2017. Cela implique que le Conseil devra nommer un nouveau directeur et représentant légal de la filiale. Cette résolution, qui nomme M. Sahel comme directeur et représentant légal de la filiale et qui lui octroie les pouvoirs spécifiques nécessaires pour gérer la filiale, garantit la poursuite d’une gestion efficace suite à la retraite du directeur et représentant légal actuel de la filiale de l’ICANN.

      Il n’y aura d’incidence fiscale sur l’ICANN que dans la mesure des couts de déplacement et d’autres dépenses connexes, mais cet impact a été pris en compte dans le budget pour l’exercice fiscal 2018.

      Cette résolution ne devrait avoir aucun impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

      Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    9. Remerciements à l’attention de l’hôte de la réunion ICANN 59

      Le Conseil d’administration tient à exprimer ses remerciements à ZADNA. Des remerciements spéciaux sont adressés à Vika Mpsane, PDG de ZADNA et à Peter Madavhu, directeur des opérations.

    10. Remerciements à l’attention du sponsor de la réunion ICANN 59

      Le Conseil tient à remercier le sponsor suivant : Verisign

    11. Remerciements à l’attention des interprètes, du personnel, des organisateurs et des équipes de l’hôtel ayant contribué à la réunion ICANN 59

      Le Conseil d’administration exprime sa gratitude aux transcripteurs, aux interprètes, à l’équipe audiovisuelle, aux équipes techniques et à l’ensemble du personnel de l’ICANN pour les efforts réalisés afin de faciliter le bon déroulement de la réunion. Le Conseil souhaite également remercier la direction et le personnel du Sandton Convention Center pour avoir prêté ces magnifiques locaux pour l’occasion. Des remerciements spéciaux sont adressés à Nasrin Hoosen, directeur commercial international, et à Janine Baltensperger, directrice des opérations. En outre, le Conseil d’administration tient également à remercier Sello Ditsoabare du Johannesburg Convention Bureau et Yoshni Singh du Gauteng Convention Bureau.

  2. Ordre du jour principal :

    1. Approbation du plan opérationnel et budget pour l’exercice fiscal 2018, du budget de l’IANA et de la mise à jour du plan opérationnel quinquennal pour le même exercice fiscal

      Attendu que, la version préliminaire du plan opérationnel et budget pour l’exercice fiscal 2018, le budget de l’IANA et la mise à jour du plan opérationnel quinquennal pour le même exercice fiscal ont été soumis à la consultation publique le 8 mars 2017, conformément aux statuts constitutifs et aux consultations menées auprès de l’organisation ICANN et du comité de finances du Conseil d’administration de l’ICANN pendant l’exercice fiscal actuel.

      Attendu que, le 19 avril 2017, le Conseil d’administration a évalué et a approuvé les demandes de budget supplémentaire des organisations de soutien (SO) et des comités consultatifs (AC).

      Attendu que, les commentaires publics reçus du forum de commentaires publics ont été discutés par les membres de l’organisation ICANN pendant plusieurs appels avec les représentants des organes de l’ICANN qui les ont soumis, et ce afin de s’assurer que les commentaires aient été bien compris et qu’ils aient reçu l’attention appropriée. Les résultats des appels et les réponses aux commentaires ont été soigneusement examinés par les membres du BFC.

      Attendu que, les commentaires publics reçus ont été analysés pour déterminer les révisions nécessaires au plan opérationnel et budget pour l’exercice fiscal 2018, au budget de l’IANA et à la mise à jour du plan opérationnel quinquennal pour le même exercice fiscal.

      Attendu que, outre le processus de consultation publique, l’ICANN a activement sollicité les commentaires et la consultation avec la communauté de l’ICANN par d’autres moyens, y compris des téléconférences, des réunions lors de la réunion ICANN 58 à Copenhague, et des échanges par courriel.

      Attendu que, lors de chacune de ses réunions régulières récentes, le Comité de finances du Conseil d’administration (BFC) en a discuté et a guidé l’organisation ICANN dans l’élaboration du plan opérationnel et budget pour l’exercice fiscal 2018, du budget de l’IANA et de la mise à jour du plan opérationnel quinquennal pour le même exercice fiscal.

      Attendu que, le BFC s’est réuni le 9 juin 2017 pour examiner et discuter les changements suggérés résultant des commentaires publics, le plan opérationnel et budget pour l’exercice fiscal 2018, le budget de l’IANA et la mise à jour du plan opérationnel quinquennal pour l’exercice fiscal 2018 finaux et a recommandé que le Conseil d’administration adopte le plan opérationnel et budget pour l’exercice fiscal 2018, le budget de l’IANA et la mise à jour du plan opérationnel quinquennal pour le même exercice fiscal.

      Attendu que, conformément à l’article 3.9 des contrats d’accréditation de bureau d’enregistrement de 2001, 2009 et 2013, respectivement, le Conseil d’administration doit établir les frais variables d’accréditation des bureaux d’enregistrement, qui doivent être établis afin d’élaborer le budget annuel.

      Attendu que, la description des frais des bureaux d’enregistrement, y compris les frais variables d’accréditation des bureaux d’enregistrement recommandés, correspondant à l’exercice fiscal 2018 ont été inclus dans le plan opérationnel et budget pour l’exercice fiscal 2018.

      Il est résolu (2017.06.24.16) que le Conseil d’administration adopte le plan opérationnel et budget de l’exercice fiscal 2018, y compris le budget intérimaire de l’ICANN de l’exercice fiscal 2018 qui sera en vigueur dès le début de l’exercice fiscal 2018 jusqu’à ce que le plan opérationnel et budget de l’exercice fiscal 2018 entre en vigueur conformément à l’article 22.4(a)(vi) des statuts constitutifs de l’ICANN. L’adoption du plan opérationnel et budget pour l’exercice fiscal 2018 établit les frais variables d’accréditation (par bureau d’enregistrement et par transaction) indiqués dans le plan opérationnel et budget pour l’exercice fiscal 2018.

      Il est résolu (2017.06.24.17) que le Conseil d’administration adopte le budget de l’IANA de l’exercice fiscal 2018, y compris le budget intérimaire de l’IANA de l’exercice fiscal 2018 qui sera en vigueur dès le début de l’exercice fiscal 2018 jusqu’à ce que le budget de l’IANA de l’exercice fiscal 2018 entre en vigueur conformément à l’article 22.4(b)(vi) des statuts constitutifs de l’ICANN.

      Il est résolu (2017.06.24.18) que le Conseil d’administration adopte la mise à jour du plan opérationnel quinquennal pour l’exercice fiscal 2018. La mise à jour du plan opérationnel quinquennal de l’exercice fiscal 2018 entrera en vigueur conformément à l’article 22.5(a)(vi) des statuts constitutifs de l’ICANN.

      Fondements des résolutions 2017.06.24.16 à 2017.06.24.18

      Conformément à l’article 22.4 des statuts constitutifs de l’ICANN, le Conseil d’administration adopte un budget annuel et le publie sur le site Web de l’ICANN. Le 8 mars 2017, les versions préliminaires du plan opérationnel et budget pour l’exercice fiscal 2018, du budget de l’IANA et de la mise à jour du plan opérationnel quinquennal pour le même exercice ont été publiés pour consultation publique. Le conseil d’administration des Identificateurs techniques publics (PTI) a approuvé le budget de la PTI le 18 janvier 2017, et ledit budget a servi d’antécédent pour le budget de l’IANA pour l’exercice fiscal 2018.

      Les versions préliminaires publiées du plan opérationnel et budget pour l’exercice fiscal 2018 et le budget de l’IANA pour le même exercice sont basées sur de nombreuses discussions avec les membres de la communauté de l’ICANN et de l’organisation ICANN, y compris les organisations de soutien, les comités consultatifs et d’autres groupes de parties prenantes, tout au long des mois précédents.

      Les commentaires reçus à partir du processus de consultation publique ont donné lieu à des révisions de la version préliminaire du plan opérationnel et budget pour l’exercice fiscal 2018 du 8 mars 2017. Ont été réalisées les consultations suivantes :

      • 8 septembre 2017 et 13 septembre 2017 – Séminaire Web communautaire sur le calendrier de planification pour l’exercice fiscal 2018.
      • 8 novembre 2016 : une séance de quatre heures a été tenue à Hyderabad par le groupe de travail chargé du budget, avec la participation de plus de 15 membres de la communauté, des membres de l’organisation ICANN et Asha Hemrajani, président du Comité de finances du Conseil d’administration (BFC), pour traiter les hypothèses sur le budget pour l’exercice fiscal 2018.
      • 14 mars 2017 : une séance de trois heures a été tenue par le groupe de travail chargé du plan opérationnel et budget pour l’exercice fiscal 2018, avec la participation de plus de 15 membres de la communauté, des membres de l’organisation ICANN et Asha Hemrajani, président du Comité de finances du Conseil d’administration (BFC).
      • 8 mai 2017 : révision/discussion avec l’Unité constitutive des utilisateurs commerciaux (BC), l’Unité constitutive des représentants de la propriété intellectuelle (IPC) et l’Unité constitutive des fournisseurs de services Internet et de services de connectivité (ISPCP) sur les commentaires publics présentés par ces groupes au sujet du plan opérationnel et budget pour l’exercice fiscal 2018 (les membres du BFC ont été informés).
      • 9 mai 2017 : révision/discussion avec le Groupe des représentants des entités non commerciales (NCSG), l’Unité constitutive des entités non commerciales (NCUC), l’Unité constitutive à but non lucratif responsable des questions opérationnelles (NPOC) et le conseil de l’Organisation de soutien aux extensions génériques (GNSO) sur les commentaires publics présentés par ces groupes au sujet du plan opérationnel et budget pour l’exercice fiscal 2018 (les membres du BFC ont été informés).
      • 15 mai 2017 : révision/discussion avec le Groupe des représentants des opérateurs de registre sur les commentaires publics présentés par ce groupe au sujet du plan opérationnel et budget pour l’exercice fiscal 2018 (membre du Conseil présent : Asha Hemrajani).

      Tous les commentaires reçus ont été pris en compte dans l’élaboration du plan opérationnel et budget pour l’exercice fiscal 2018, le budget de l’IANA et le plan opérationnel quinquennal mis à jour pour le même exercice. Lorsque cela a été possible et approprié, ces commentaires ont été incorporés au plan opérationnel et budget final de l’exercice 2018 ainsi qu’au budget de l’IANA et à la mise à jour du plan opérationnel quinquennal pour le même exercice proposés pour adoption.

      Outre les exigences opérationnelles quotidiennes, le plan opérationnel et budget pour l’exercice fiscal 2018 comprend les postes du budget des nouveaux gTLD pour l’exercice fiscal 2018, ainsi que les montants affectés à diverses demandes de budget pour le même exercice fiscal formulées par les dirigeants de la communauté. Le plan opérationnel et budget pour l’exercice fiscal 2018 divulgue également des informations financières sur le programme des nouveaux gTLD, en lien avec les dépenses, les revenus et les fonds de réserve nets. Par ailleurs, étant donné que les frais variables d’accréditation de bureaux d’enregistrement sont un pivot de l’élaboration du budget, le plan opérationnel et budget pour l’exercice fiscal 2018 détermine ces frais, qui sont cohérents avec ceux des dernières années et seront soumis à l’approbation des bureaux d’enregistrement.

      Le plan opérationnel et budget pour l’exercice fiscal 2018, le budget de l’IANA et la mise à jour du plan opérationnel quinquennal pour le même exercice, auront tous un impact positif sur l’ICANN, car ils donnent à l’ICANN un cadre approprié de gestion et d’opération ainsi que la base pour que l’organisation demeure responsable de manière transparente. Un impact fiscal est à prévoir sur l’ICANN et sur la communauté. Des effets positifs sont à prévoir sur la sécurité, la stabilité et la résilience du système des noms de domaine (DNS) eu égard aux financements consacrés à ces aspects du DNS.

      Il s’agit d’une fonction administrative organisationnelle qui, comme indiqué ci-dessus, a déjà fait l’objet d’une consultation publique.

    2. Considération des recommandations du SSAC sur le registre des avis du Conseil d’administration : SAC062, SAC063, SAC064, SAC065, SAC070 et SAC073

      Attendu que, le Comité consultatif sur la sécurité et la stabilité (SSAC) a présenté les recommandations figurant dans les documents SAC : SAC062, SAC063, SAC064, SAC065, SAC070 et SAC073.

      Attendu que, l’organisation ICANN a évalué la faisabilité des avis du SSAC et a élaboré des recommandations de mise en œuvre pour chacun d’eux.

      Attendu que, le Conseil d’administration a examiné l’avis du SSAC et les recommandations de mise en œuvre émises par l’organisation ICANN concernant cet avis.

      Il est résolu (2017.06.24.19) que le Conseil d’administration adopte les recommandations du SSAC décrites dans le document intitulé « Recommandations pour la mise en œuvre de l’avis du SSAC : documents SAC062, SAC063, SAC064, SAC065, SAC070 et SAC073 (8 juin 2017) [PDF, 433 KB] » et enjoint au PDG d’appliquer l’avis tel qu’il est décrit dans le document.

      Fondements de la résolution 2017.06.24.19

      Le registre de demandes d’intervention est un cadre visant à améliorer le processus par lequel le Conseil d’administration analyse les recommandations qui lui sont adressées, y compris l’avis de ses comités consultatifs. Ce cadre est en cours d’élaboration depuis 2015 et, dans le cadre de son effort initial, l’organisation ICANN a examiné les avis du SSAC émis entre 2010 et 2015 pour identifier les éléments qui n’avaient pas encore été considérés par le Conseil d’administration. Les résultats de cette révision initiale ont été communiqués au président du SSAC dans une lettre du président du Conseil d’administration de l’ICANN, en date du 19 octobre 2016 (voir https://www.icann.org/en/system/files/correspondence/crocker-to-faltstrom-19oct16-en.pdf [PDF, 627 Ko]). Cette résolution vise à répondre à plusieurs des éléments ayant été recensés comme ouverts à l’époque, ainsi que deux éléments identifiés comme faisant partie du processus « pilote ».

      Dans le cadre du registre de demandes d’intervention, pour chaque élément de l’avis présenté avec cette résolution, l’organisation ICANN a examiné la demande du SSAC, a confirmé l’avoir comprise auprès de celui-ci et a évalué sa faisabilité. L’organisation ICANN présente ses recommandations au Conseil d’administration afin que celui-ci puisse examiner formellement l’avis et charger le PDG d’aborder l’avis comme il convient.

      Les documents d’information sur chaque avis sont fournis ci-dessous :

      Le document SAC062 recommande à l’ICANN de travailler avec la communauté Internet mondiale afin d’identifier quelles chaines ne devraient pas être réservées pour l’utilisation de l’espace de noms privé et quel type d’utilisation de l’espace de noms privé est approprié. Le bureau du directeur de la technologie de l’ICANN travaille toujours activement dans le groupe de travail de l’IETF sur les opérations du DNS (DNSOP) afin de prévoir un processus destiné à réserver des noms à usage spécial. Cet effort mettra à jour le RFC6761 (voir https://www.icann.org/en/system/files/files/sac-062-en.pdf [PDF, 375 KB]).

      Le document SAC063 recommande au personnel de l’ICANN de mener, de coordonner et d’encourager par d’autres moyens la création d’une plateforme d’essai pour analyser les comportements de mise en œuvre du résolveur de validation pouvant affecter ou être affecté par le roulement de la KSK de la zone racine. Dans le cadre du projet de roulement de la KSK de la zone racine, le bureau du directeur de la technologie de l’ICANN poursuit son travail avec la plateforme d’essai de résolveur que l’équipe de recherche a créée pour étudier le comportement des validateurs DNSSEC dans diverses conditions de fonctionnement. (Voir https://www.icann.org/en/system/files/files/sac-063-en.pdf [PDF, 480 KB])

      Le document SAC064 aborde le comportement du traitement de la « liste de recherche ». Dans ce contexte, une liste de recherche est une liste de domaines qui sont ajoutés aux données de l’utilisateur d’un nom de domaine partiel afin de former un nom de domaine complètement qualifié. La recommandation 2 suggère que le personnel de l’ICANN devrait travailler avec la communauté du DNS et l’IETF afin d’encourager la normalisation du comportement du traitement de la liste de recherche. La recommandation 3 suggère des façons d’examiner le comportement de la liste de recherche qui pourrait aider à atténuer les collisions de noms. Le personnel de l’ICANN peut faciliter les deux recommandations bien que, dans ce cas, il pourrait y avoir une incidence sur les couts et les ressources. (Voir https://www.icann.org/en/system/files/files/sac-064-en.pdf [PDF, 931 KB].)

      Le document SAC065 est un avis sur les attaques DDoS à travers l’infrastructure du DNS et la recommandation 1 indique que l’ICANN devrait contribuer à faciliter un effort de la communauté à l’échelle de l’Internet pour réduire le nombre de résolveurs ouverts et de réseaux qui permettent l’usurpation de réseaux. Pour cet effort de la communauté, l’ICANN devrait fournir du soutien en matière de mesures et de sensibilisation avec l’affectation de personnel et de financement appropriés. (Voir https://www.icann.org/en/system/files/files/sac-065-en.pdf [PDF, 423 KB].)

      Le document SAC070 est un avis sur les listes publiques de suffixes (PSL). Bien que la définition d’une PSL ne soit pas consensuelle, le SAC la définit comme « un domaine sous lequel plusieurs parties qui ne sont pas rattachées au propriétaire du suffixe public peuvent enregistrer des sous-domaines ». Il existe de multiples PSL, mais celle de la Fondation Mozilla semble être la plus largement acceptée. La recommandation 3 suggère que l’ICANN travaille avec la Fondation Mozilla pour créer des documents d’information sur la PSL de celle-ci pouvant être diffusés aux opérateurs de registre. La recommandation 4a suggère que la communauté Internet devrait normaliser l’approche aux PSL, et que l’ICANN et le travail effectué en matière d’acceptation universelle devraient inciter la communauté de développement de logiciels à appuyer l’utilisation des PSL.

      La recommandation 5 suggère que l’IANA devrait héberger une PSL contenant des informations sur les domaines dans les registres avec lesquels l’IANA est en communication directe. La recommandation 6 suggère que les parties qui travaillent sur l’acceptation universelle, comme l’UASG, se penchent sur l’utilisation d’une PSL et les actions d’une PSL dans le cadre de leur travail. L’ICANN peut mener une consultation avec la Fondation Mozilla et la communauté de l’ICANN dans son ensemble sur le besoin de disposer de documents éducatifs et, si c’était le cas, le bureau du directeur de la technologie de l’ICANN devrait en tenir compte pour établir les priorités de ses projets en cours ainsi que les couts et d’autres facteurs. Le Groupe directeur sur l’acceptation universelle (UASG) recommande que les TLD soient validés si nécessaire et fait spécifiquement référence au document SAC070 dans la documentation de l’UA. Toutefois, l’UASG déconseille actuellement l’utilisation de la PSL de la Fondation Mozilla car l’UASG n’est pas sûr que ce soit la PSL faisant autorité. Ce n’est pas clair non plus si cela représenterait un avantage pour l’IANA de créer et d’héberger une PSL distincte, car la PSL de la Fondation Mozilla est la plus utilisée. Il serait nécessaire de consulter la communauté à cet égard. (Voir https://www.icann.org/en/system/files/files/sac-070-en.pdf [PDF, 955 KB].)

      Le document SAC073 contient des commentaires sur le Plan de roulement de la clé de signature de clé (KSK) de la zone racine, abordant les sujets suivants : La terminologie et les définitions relatives au roulement de clé du DNSSEC dans la zone racine, la gestion des clés dans la zone racine, les motivations pour le roulement de la KSK de la zone racine, les risques associés au roulement de la KSK de la zone racine, les mécanismes pour le roulement de la KSK de la zone racine, la quantification du risque de défaillance dans la mise à jour de l’ancre de confiance et les considérations sur la taille de la réponse du DNS. Le bureau du directeur de la technologie de l’ICANN et les Identificateurs techniques publics (PTI) sont conjointement responsables de la planification et de l’exécution du roulement de la KSK de la zone racine. Tel que cela est demandé dans le document SAC073, un rapport devrait être élaboré pour aborder les commentaires du document SAC073. (Voir https://www.icann.org/en/system/files/files/sac-073-en.pdf [PDF, 541 KB].)

    3. Considération de la recommandation révisée du Comité de gouvernance du Conseil d’administration sur les demandes de réexamen 13-16 et 14-10

      Attendu que, .Sport Limited (le demandeur) a déposé les demandes de réexamen 13-16 et 14-10 contestant la décision de l’expert qui fait prévaloir l’objection de la communauté déposée contre la candidature du demandeur pour la chaine .SPORT (décision de l’expert) au motif que l’expert ayant présidé la procédure d’objection a omis de divulguer certains éléments de preuve s’agissant de sa partialité.

      Attendu que, le Comité de gouvernance du Conseil d’administration (BGC) a rejeté préalablement la demande 13-16 et a recommandé au Conseil d’administration de rejeter la demande 14-10, et que le Conseil (à travers le Comité du programme des nouveaux gTLD (NGPC)) a été d’accord, parce que les demandes ne supportaient pas le réexamen pour les raisons exposées dans la décision du BGC sur la demande 13-16 [PDF, 184 KB] et la décision du NGPC sur la demande 14-10.

      Attendu que, le demandeur a engagé un processus de révision indépendante (IRP) contre l’ICANN, contestant la décision de l’expert et le rejet des demandes 13-16 et 14-10 de la part du BGC et du Conseil d’administration.

      Attendu que, le panel IRP a déclaré que le demandeur est la partie gagnante et a recommandé que le « Conseil d’administration reconsidère ses décisions sur les demandes de réexamen, dans l’ensemble, appréciant les nouveaux éléments de preuve dans leur intégralité selon la norme applicable aux tiers neutres qui est énoncée dans les lignes directrices de l’IBA relatives aux conflits ». (Déclaration finale [PDF, 518 KB] au ¶ 9.1(b).)

      Attendu que, le 16 mars 2017, le Conseil d’administration a adopté la recommandation du panel IRP et a indiqué au BGC de réévaluer les demandes de réexamen pertinentes.

      Attendu que, le BGC a examiné attentivement si la prétendue preuve de partialité apparente aurait dû être divulguée par l’expert à la lumière des lignes directrices de l’IBA relatives aux conflits, ainsi que du rapport publié par l’ombudsman après la décision du Conseil d’administration sur la demande 14-10.

      Attendu que, le BGC a recommandé que les demandes de réexamen 13-16 et 14-10 soient encore une fois rejetées, outre les motifs énoncés dans la première décision du BGC sur la demande 13-16 [PDF, 184 KB] et la décision du NGPC sur la demande 14-10, parce que la prétendue preuve de partialité ne « suscite pas de doutes quant à l’impartialité ou l’indépendance de l’arbitre » sous les lignes directrices de l’IBA relatives aux conflits et, par conséquent, le demandeur n’a pas indiqué de motifs valables pour le réexamen, et le Conseil est d’accord.

      Attendu que, le Conseil d’administration a examiné attentivement la lettre supplémentaire que le demandeur a présenté le 14 juin 2017 et conclut que la lettre ne fournit aucun argument supplémentaire ni aucune preuve à l’appui du réexamen.

      Il est résolu (2017.06.24.20) que le Conseil d’administration adopte la recommandation supplémentaire du BGC concernant les demandes de réexamen 13-16 et 14-10 [PDF, 365 KB].

      Fondements de la résolution 2017.06.24.20

      1. Bref récapitulatif

        .Sport Limited (le demandeur) et SportAccord ont tous deux déposé leur candidature pour la chaine .SPORT et sont dans le même ensemble conflictuel. SportAccord a déposé une objection de la communauté (objection) contre la candidature du demandeur (candidature). L’expert a rendu une décision en faveur de SportAccord (décision de l’expert). (Voir https://newgtlds.icann.org/sites/default/files/drsp/04nov13/determination-1-1-1174-59954-en.pdf [PDF, 173 KB].) Le demandeur a alors déposé deux demandes de réexamen — la demande 13-16 et la demande 14-10 [PDF, 867 KB], contestant la nomination de l’expert par le Centre international d’expertise de la Chambre de commerce internationale (ICC), affirmant que l’expert aurait violé la politique ou le processus établi en omettant de divulguer des renseignements importants concernant sa nomination. Les demandes 13-16 et 14-10 ont été refusées par le BGC et le NGPC, respectivement, parce que les motifs ne justifiaient pas de réexamen. (Voir la décision du BGC sur la demande de réexamen 13-16,https://www.icann.org/en/system/files/files/determination-sport-08jan14-en.pdf [PDF, 184 KB]; et la décision du NGPC sur la demande de réexamen 14-10 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-18-en.) À la suite de la décision du NGPC sur la demande 14-10, le demandeur a déposé une nouvelle requête auprès de l’ombudsman. Le 25 aout 2014, l’ombudsman a publié un rapport final sur la nouvelle plainte du demandeur (Rapport final de l’ombudsman).1

        Le demandeur a alors initié un IRP. Le 31 janvier 2017 [PDF, 518 KB], le panel IRP a déclaré que le demandeur est la partie gagnante et a recommandé au Conseil d’administration de reconsidérer les demandes de réexamen 13-16 et 14-10 « dans l’ensemble, appréciant les nouveaux éléments de preuve dans leur intégralité selon la norme applicable aux tiers neutres énoncée dans les [lignes directrices de l’Association internationale du barreau sur les conflits d’intérêts dans l’arbitrage international] » (lignes directrices de l’IBA relatives aux conflits ou lignes directrices). (Voir la déclaration finale, ¶ 9.1(a)-(b), https://www.icann.org/en/system/files/files/irp-dot-sport-final-declaration-31jan17-en.pdf [PDF, 518 KB].) Le 16 mars 2017, le Conseil d’administration de l’ICANN a accepté la recommandation du panel IRP et a indiqué au BGC de réévaluer les demandes de réexamen pertinentes.

        Le BGC a examiné attentivement si la prétendue preuve de partialité apparente aurait dû être divulguée par l’expert à la lumière des lignes directrices de l’IBA relatives aux conflits. Le BGC a également évalué le rapport final de l’ombudsman, qui a été délivré après la décision du NGPC sur la demande 14-10. Le BGC a conclu, et le Conseil d’administration est d’accord, que les prétentions du demandeur ne sont pas justifiées, car la prétendue preuve de partialité ne « suscite pas de doutes quant à l’impartialité ou à l’indépendance de l’arbitre » aux termes des lignes directrices de l’IBA relatives aux conflits. (Voir la norme générale 3(a). des lignes directrices de l’IBA de 2004 relatives aux conflits). Le BGC a fait remarquer que ses conclusions précédentes au sujet du respect des délais ne sont pas pertinentes pour la réévaluation des demandes de réexamen 13-16 et 14-10. Par conséquent, le BGC a recommandé que les demandes 13-16, 14-10 soient à nouveau refusées et le Conseil d’administration est d’accord.

        Le 14 juin 2017, le demandeur a présenté une lettre au Conseil d’administration de l’ICANN réfutant la recommandation du BGC sur les demandes 13-16 et 14-10, que le Conseil a examinée et estime ne constitue pas de base pour un réexamen (lettre du 24 juin 2017). (https://www.icann.org/en/system/files/files/reconsideration-13-16-et-al-dot-sport-crowell-moring-to-icann-board-redacted-14jun17-en.pdf [PDF, 903 KB].)

        Le Conseil d’administration fait remarquer que les demandes 13-16 et 14-10 aux fins du réexamen ont invoqué d’autres motifs en plus des conflits présumés. Ces réclamations supplémentaires ne font pas partie de la réévaluation du BGC. Le Conseil (par le biais du BGC et du NGPC) a évalué au préalable ces réclamations supplémentaires dans la décision du BGC sur la demande 13-16 [PDF, 184 KB] et la décision du NGPC sur la demande 14-10. Il estime que ses conclusions précédentes sur ces réclamations supplémentaires ne faisant pas partie de la recommandation du BGC sur les demandes 13-16 et 14-10 [PDF, 365 KB] sont toujours applicables.

      2. Les faits

        Le contexte factuel complet, dont le Conseil a tenu compte, est énoncé dans la recommandation supplémentaire du BGC sur les demandes 13-16 et 14-10 [PDF, 365 KB] et a été incorporé ici.

        Après la publication de la recommandation du BGC sur les demandes 13-16 et 14-10, le demandeur a soumis la lettre du 14 juin 2017 [PDF, 903 KB], que le Conseil a examinée.

      3. Normes applicables pour évaluer les demandes de réexamen et les objections de la communauté.

        Les statuts constitutifs en vigueur au moment où les demandes de réexamen 13-16 et 14-10 ont été déposées établissent que le BGC devrait évaluer et, éventuellement, rendre une décision ou faire des recommandations au Conseil d’administration en ce concernant les demandes de réexamen. (Voir le chapitre IV, article 2, des statuts constitutifs en vigueur à partir du 11 avril 2013, https://www.icann.org/resources/pages/bylaws-2014-04-04-en#IV et le chapitre IV, article 2 des statuts constitutifs en vigueur à partir du 7 février 2014, https://www.icann.org/resources/pages/bylaws-2014-10-06-en#IV.) L’ICANN a déjà déterminé que le processus de réexamen peut être invoqué pour contester les décisions d’expert relatives aux nouveaux gTLD, rendues par des panels composés de fournisseurs de services de règlement de litiges tiers, comme l’ICC, lorsqu’il peut être déclaré que le fournisseur n’a pas suivi les politiques ou processus établis qu’il est tenu de suivre pour parvenir à la décision de l’expert, ou que le personnel n’a pas respecté ses politiques ou processus en acceptant cette décision. (Voir la recommandation du BGC sur la demande de réexamen 13-5, disponible à https://www.icann.org/en/system/files/files/recommendation-booking-01aug13-en.pdf [PDF, 117 KB].) Le processus de réexamen n’exige pas du BGC qu’il effectue une révision de fond des décisions de l’expert. En conséquence, la révision du BGC ne devait pas évaluer la conclusion du panel de l’ICC selon laquelle une partie importante de la communauté se serait manifestée majoritairement en opposition à la candidature du demandeur de .SPORT du fait qu’elle pouvait en être la cible. La révision du BGC était plutôt limitée à déterminer si l’expert a violé les lignes directrices de l’IBA relatives aux conflits comme le suggère le demandeur lorsque l’expert a omis de divulguer le contrat de DirecTV, la relation avec TyC et sa participation à titre de coprésident d’un panel lors de la conférence, tel que ces termes sont définis ci-dessous. Le Conseil d’administration fait remarquer que les demandes 13-16 et 14-10 aux fins du réexamen ont invoqué d’autres motifs en plus des conflits présumés. Ces motifs supplémentaires ne font pas partie de la réévaluation du BGC. Le Conseil d’administration (par le biais du BGC et du NGPC) a évalué au préalable ces motifs supplémentaires dans la décision du BGC sur la demande 13-16 [PDF, 184 KB] et la décision du NGPC sur la demande 14-10. Le Conseil estime que ses décisions précédentes sur ces motifs supplémentaires, ne faisant pas partie de la Recommandation du BGC sur les demandes 13-16 et 14-10 [PDF, 365 KB], sont toujours applicables.

        Le Conseil d’administration a examiné en profondeur la recommandation supplémentaire du BGC relative aux demandes de réexamen 13-16 et 14-10 [PDF, 365 KB] et considère que l’analyse est fondée.

      4. Analyse et fondements

        Le BGC a conclu, et le Conseil est d’accord, que les lignes directrices de l’IBA relatives aux conflits n’imposent pas à l’expert de divulguer que : (i) DirecTV, un client du cabinet de l’expert, a acquis les droits de retransmission des Jeux olympiques du CIO le 7 février 2014 (le contrat de DirecTV) ; (ii) un partenaire du cabinet d’avocats de l’expert est le président de Torneos y Competencias S.A. (TyC), une entreprise qui, historiquement, a acquis les droits de retransmission des Jeux olympiques (la relation de TyC) ; ou (iii) l’expert a coprésidé un panel, lors d’une conférence tenue en février 2011 (« Conférence »), intitulé « La quête visant à optimiser le processus de règlement de litiges dans les grandes manifestations sportives ». En conséquence, comme l’expert n’était pas tenu de divulguer, en vertu des lignes directrices de l’IBA relatives aux conflits, aucune des conduites présumées ayant donné lieu aux allégations de partialité apparente de la part du demandeur, le réexamen n’est pas justifié.

        4,1. Les lignes directrices de l’IBA relatives aux conflits n’imposent ni la divulgation du contrat de DirecTV ni de la relation de TyC.

        Contrairement aux allégations du demandeur, les lignes directrices de l’IBA relatives aux conflits n’exigent pas que l’expert divulgue le contrat de DirectTV ni la relation de TyC. Les exigences de divulgation pour les tiers neutres sont généralement évaluées conformément aux lignes directrices de l’IBA relatives aux conflits. Les lignes directrices de l’IBA relatives aux conflits de 2004, qui étaient en vigueur au cours des procédures d’objection, imposent, en général, à un expert de l’ICC de divulguer « des circonstances ou des faits [. . .] pouvant, aux yeux des parties, susciter des doutes quant à l’impartialité ou l’indépendance de l’arbitre ». (norme générale 3(a). des lignes directrices d’IBA de 2004 relatives aux conflits).

        Pour tenter de parvenir à « une plus grande cohérence, à moins de contestations et retraits inutiles de l’arbitre », les lignes directrices présentent des « listes de situations spécifiques … qui imposent ou pas la divulgation ou la récusation d’un arbitre » (Liste d’application des lignes directrices). (Voir id. au ¶ 3.) Les listes sont désignées : rouge, orange et verte.

        Les cas énoncés sur la liste rouge doivent être divulgués aux parties et l’expert sera récusé à moins que les parties renoncent effectivement au conflit. (Voir id. au § II.2.) Un expert est tenu de divulguer les questions figurant sur la liste orange, mais il ne sera récusé que si les parties présentent effectivement une objection au conflit. (Voir id. au § II.3.) En outre, même si une partie présente une objection à une divulgation de la liste orange, un expert peut toujours être nommé si l’autorité statuant sur la contestation décide que celle-ci ne répond pas au critère objectif de qualification. (Voir id. au § II.4.) Les conduites figurant sur la liste verte n’ont pas du tout besoin d’être divulguées. (Voir id. au § II.6.)

        Les lignes directrices de l’IBA de 2004 relatives aux conflits précisent qu’une « contestation ultérieure fondée sur le fait qu’un arbitre n’a pas divulgué » des faits ou des circonstances dans la catégorie orange « ne devrait entrainer automatiquement ni la non-nomination, ni la disqualification ultérieure, ni l’invalidation d’une décision [. . .] La non-divulgation ne peut pas rendre un arbitre biaisé ou manquant d’indépendance ; seuls les faits ou les circonstances qu’il ou elle n’a pas divulgués peuvent le faire ». (Id. au § II.5.)

        Le panel IRP et l’ombudsman dans son rapport final ont dégagé plusieurs lignes directrices qu’ils considéraient comme étant potentiellement invoquées par le contrat de DirecTV et la relation de TyC. Le BGC et le Conseil d’administration ont examiné soigneusement les lignes directrices dans leur intégralité, y compris les parties citées par le panel IRP et l’ombudsman. Comme discuté ci-dessous, le BGC a conclu, et le Conseil d’administration est d’accord, que les lignes directrices n’exigent pas que l’expert divulgue le contrat de DirecTV ou la relation de TyC.

        4.1.1. Directives 4.2.1 et 3.4.1 (adversaire d’un cabinet d’avocats)

        L’ombudsman a avancé que la directive 4.2.1 était sans doute invoquée par la représentation de DirecTV par le cabinet d’avocats de l’expert dans le cadre des négociations avec le CIO. (Voir la recommandation du BGC sur les demandes de réexamen 13-16 et 14-10 [PDF, 365 KB] à la pièce jointe 1). La directive 4.2.1 catégorise comme verte (c’est-à-dire sans aucune exigence de divulgation) la circonstance où « [L]e cabinet d’avocats de l’arbitre a agi contre une des parties ou une société affiliée de l’une des parties dans une autre affaire sans l’intervention de l’arbitre ». (Liste d’applications des lignes directrices de l’IBA relatives aux conflits de 2004, au ¶ 4.2.1.)

        Après une analyse minutieuse, le BGC a conclu, et le Conseil d’administration est d’accord, que la ligne directrice 4.2.1 ne se prête pas aux circonstances dans ce cas-ci parce que le CIO n’est pas une société affiliée à SportAccord, comme nous le verrons plus loin. Toutefois, même si la ligne directrice 4.2.1 était applicable, elle n’exige pas la divulgation. En conséquence, la ligne directrice 4.2.1 ne peut pas justifier le réexamen. Notamment, l’ombudsman a reconnu dans son rapport final que la ligne directrice 4.2.1 « ne fait pas tout à fait le point », mais trouve qu’elle est l’ensemble de faits les « plus proches » à la représentation de DirecTV par le cabinet d’avocats de l’expert dans le cadre des négociations avec le CIO. L’ombudsman a ajouté que bien que « [l]es lignes directrices parlent des sociétés affiliées des parties », les « connexions » dans ce cas n’étaient « pas si claires ». Le BGC a été d’accord, ainsi que le Conseil d’administration, dans la mesure où SportAccord n’a pas des relations d’affaires, commerciales, ou autres avec le CIO, mais tout simplement participe de la même industrie, comme nous le verrons plus loin. De toute façon, comme l’ombudsman l’a fait remarquer, même si la ligne directrice 4.2.1 en a fait le point, les adversités passées du cabinet d’avocats de l’arbitre envers une partie ou une société affiliée sont sur la liste verte, il n’y a donc pas besoin qu’elles soient divulguées.

        En outre, le BGC et le Conseil d’administration se sont penchés sur la ligne directrice 3.4.1. La ligne directrice 3.4.1, catégorisée comme orange (c.-à-d., divulgation exigée), aborde le cas où « [l]e cabinet d’avocats de l’arbitre est actuellement contraire à une des parties ou à une société affiliée de l’une des parties, » qu’elle classe dans la liste orange. La ligne directrice 3.4.1 ne s’applique pas ici parce que le cabinet d’avocats de l’expert était défavorable au CIO dans sa représentation de DirecTV. Le CIO n’était ni une partie de l’objection ni une société affiliée d’une partie. Les lignes directrices de l’IBA relatives aux conflits établissent clairement que le terme société affiliée est utilisé pour décrire différentes entités « d’un même groupe de sociétés », y compris les entités ayant une relation maison mère-filiale ou sœur avec les sociétés contrôlées par la même entité parente. (Explication des lignes directrices de l’IBA relatives aux conflits de 2004 6(b) ; Id. note 5 de la liste d’applications). En ce qui concerne les sociétés affiliées, les lignes directrices sont spécifiquement axées sur les entités possédant une « influence déterminante » sur l’une des parties. (Id. Explication 6(c).)

        Comme le demandeur le reconnait, SportAccord est une organisation qui chapeaute toutes les fédérations sportives (olympiques et non olympiques) ainsi que les organisateurs de jeux multisports et les associations internationales liées au sport. SportAccord a quatre-vingt-douze membres à part entière ; le CIO ne se trouve pas parmi eux. (Voir http://www.olympic.org/ioc-members-list.) SportAccord n’est pas non plus membre du CIO. (Id.) Dans une industrie interconnectée comme l’industrie sportive internationale, le simple fait que : (1) le site Web du CIO note que SportAccord est l’une des nombreuses associations organisant des fédérations sportives reconnues par le CIO ; et que (2) deux des six membres du Conseil exécutif de SportAccord figurent au nombre des 102 membres du CIO ne démontre pas une affiliation. Ces faits ne créent pas une affiliation entre les deux entités comparable à une affiliation entre deux membres du même groupe de sociétés. (Voir l’explication des lignes directrices de l’IBA relatives aux conflits de 2004 6(b).) Finalement, il n’y a rien qui montre, de la part du demandeur ou autrement, que le CIO a une « influence déterminante » sur SportAccord suite à une affiliation ou autrement. Par conséquent, la directive 3.4.1 n’impose pas la divulgation du contrat de DirecTV.

        4.1.2. Directive 2.3.6 (relation commerciale importante du cabinet d’avocats)

        La directive 2.3.6 catégorise comme rouge (c.-à-d., divulgation exigée) la circonstance lorsque le « cabinet d’avocats de l’arbitre a actuellement une importante relation commerciale avec une des parties ou une société affiliée à une des parties ». Le panel IRP a déclaré que la ligne directrice 2.3.6 a été invoquée et a recommandé que l’ICANN examine si l’expert est tenu de divulguer la « relation » de son cabinet d’avocats avec TyC. (Voir la déclaration finale de l’IRP au ¶ 7.91(b).) Cette « relation » réside dans le fait qu’un partenaire du cabinet d’avocats de l’expert est le président de TyC et que le cabinet d’avocats de l’expert a représenté TyC dans les négociations pour les droits de retransmission des Jeux olympiques du CIO.

        La ligne directrice 2.3.6 reflète le point de vue de l’IBA selon lequel toute personne ayant un « intérêt économique significatif en la question visée » ne devrait pas servir d’arbitre dans cette affaire. Cela du fait que si une partie a un intérêt financier dans le résultat d’un arbitrage, cette partie ne peut pas être – ou sera perçue comme n’étant pas – impartiale et indépendante dans l’affaire. (Explication des lignes directrices de l’IBA relatives aux conflits de 2004 2(d). En conséquence, la ligne directrice 2.3.6 interdit la nomination d’un arbitre dont le cabinet maintient actuellement une « importante relation commerciale » avec une des parties ou une société affiliée d’une partie.

        Les raisons de l’IBA pour l’élaboration de la ligne directrice 2.3.6 ne sont pas applicables ici. La « relation » du cabinet d’avocats de l’expert avec TyC est limitée du fait qu’un autre partenaire du cabinet est le président de TyC et la société — pas l’expert — a représenté TyC. Le demandeur n’a pas démontré que le cabinet lui-même ait une forte participation financière (ou aucune) dans TyC ou que les affaires de TyC aient une incidence sur les finances du cabinet d’avocats. Le demandeur n’a présenté aucune preuve à l’appui de sa déclaration selon laquelle l’expert — ou son cabinet d’avocats — aurait reçu un avantage, commercial ou autre, pour trancher pour ou contre SportAccord.

        Enfin, même si le cabinet d’avocats de l’expert a eu une importante relation commerciale avec TyC, TyC n’est pas une partie ou une société affiliée de SportAccord. TyC était, au minimum, contraire et défavorable aux droits de retransmission des Jeux olympiques tels que négociés entre le CIO et TyC. Le demandeur n’a pas affirmé que TyC avait de relation actuelle avec la partie en question, SportAccord, sauf à travers le CIO, qui comme indiqué ci-dessus n’est pas une société affiliée à SportAccord. Pour cette raison supplémentaire, le paragraphe 2.3.6 des lignes directrices de l’IBA relatives aux conflits n’exige pas que l’expert divulgue la relation avec TyC.

        4.1.3. Directives 3.1.4, 3.2.1 et 3.2.3 (client d’une partie)

        Parce que le CIO n’est ni une partie ni une société affiliée à une partie de l’objection, le BGC a conclu, et le Conseil est d’accord, que les lignes directrices restantes — lignes directrices 3.1.4, 3.2.1 et 3.2.3 —que le panel IRP a considérées comme vraisemblablement applicables aux réclamations du demandeur ne peuvent pas être interprétées comme obligeant l’expert à divulguer la relation de TyC ou le contrat de DirecTV.

        La ligne directrice 3.1.4, classée orange, s’applique au cas où « [l]e cabinet d’avocats de l’arbitre aurait, au cours des trois dernières années, agi pour une des parties ou une société affiliée d’une des parties dans une affaire tout à fait différente sans l’intervention de l’arbitre ». La directive 3.2.1, classée orange, s’applique au cas où « [l]e cabinet d’avocats de l’arbitre rendrait actuellement des services à l’une des parties ou à une société affiliée de l’une des parties sans créer une relation commerciale importante et sans l’intervention de l’arbitre ». La directive 3.2.3, classée orange, s’applique au cas où « [l’]arbitre, ou sa société, représenterait régulièrement une partie ou une société affiliée à l’arbitrage, mais n’est pas impliqué dans le conflit actuel ».

        Le demandeur n’a pas identifié une partie ou une société affiliée d’une partie étant un client du cabinet d’avocats de l’expert, et, tel que cela a été discuté, le CIO n’est pas une partie ou une société affiliée à une partie. En conséquence, aucune des lignes directrices susmentionnées n’est analogue aux conflits prétendus que le demandeur a cités ici.

        Finalement, les lignes directrices de l’IBA relatives aux conflits reconnaissent que la « taille croissante des cabinets d’avocats » peut limiter indument la capacité d’une partie d’« utiliser l’arbitre de son choix ». (Explication des lignes directrices de l’IBA relatives aux conflits de 2004 6(a).) En conséquence, « les activités du cabinet d’avocats de l’arbitre » ne peuvent pas « constituer automatiquement une source de [. . .] conflit ou un motif de divulgation ». (Id., à la norme générale 6(a).) Interpréter les lignes directrices de l’IBA relatives aux conflits comme exigeant la divulgation de relations du cabinet d’avocats aussi faiblement en rapport avec le sujet du litige que la relation de TyC et le contrat de DirecTV le sont avec l’objection imposerait une limite inutile et excessive en ce concernant la capacité des parties d’« utiliser le ou les arbitres de leur choix ». Le BGC a conclu qu’il ne pouvait pas recommander ce résultat et le Conseil d’administration est d’accord.

        4.2 Les lignes directrices de l’IBA relatives aux conflits ne nécessitent pas la divulgation de la présentation de l’expert lors de la conférence sur le règlement de litiges.

        Le demandeur affirme également que l’expert aurait dû lui communiquer sa participation à un programme de février 2011 intitulé « [l]a quête visant à optimiser le processus de règlement de litiges dans les grandes manifestations sportives » lors d’une conférence destinée, entre autres, aux « dirigeants de la fédération sportive ». Le BGC a conclu, et le Conseil est d’accord, qu’aucune des règles des lignes directrices de l’IBA relatives aux conflits n’exige une telle divulgation.

        Le panel IRP a suggéré que la ligne directrice 3.5.2 des lignes directrices de l’IBA relatives aux conflits est pertinente pour déterminer si l’expert est tenu de divulguer sa participation à un panel. La ligne directrice 3.5.2 s’applique au cas où « [l’]arbitre aurait publiquement défendu une position spécifique au sujet de l’affaire qui est actuellement soumise à l’arbitrage, que ce soit dans un document publié ou une allocution ou autrement ». La ligne directrice 3.5.2 fait partie de la liste orange.

        La ligne directrice 3.5.2 s’appliquerait uniquement si l’expert « avait publiquement défendu une position spécifique en ce qui concerne l’affaire actuellement soumise à l’arbitrage » (italiques ajoutés), ce que l’expert n’a pas fait ici. Au contraire, l’expert a participé à la conférence en question en février 2011, plus de deux ans avant le dépôt de l’objection de la part de SportAccord et presque deux ans avant la nomination de l’expert de la part de l’ICC pour examiner l’objection. Par conséquent, il est logiquement impossible que la présentation de l’expert de 2011 préconise une position spécifique au sujet de l’objection, car l’objection n’avait pas été déposée et ne serait déposée que deux ans après la conférence. En outre, le demandeur n’a pas affirmé que l’expert ait préconisé une position spécifique au sujet de l’objection lors de la conférence ; plutôt, le demandeur fait valoir simplement que la conférence « vise les [. . .] dirigeants de la fédération sportive ». L’identification d’un public cible pour une conférence ne veut pas dire « préconiser une position spécifique sur l’affaire actuellement soumise à l’arbitrage », tel que cela est requis pour invoquer la ligne directrice 3.5.2.

        L’IBA a publié des lignes directrices relatives aux conflits mises à jour en 2014, ce qui, bien que publié après la nomination de l’expert, fournit une orientation supplémentaire en matière de divulgation des conflits. Les lignes directrices de l’IBA relatives aux conflits de 2014 ont en outre précisé qu’un « arbitre doit, en principe, être considéré comme portant l’identité de son cabinet, mais les activités du cabinet de l’arbitre ne devraient pas automatiquement créer un conflit d’intérêts. La pertinence des activités du cabinet de l’arbitre [. . .] et la relation de l’arbitre avec le cabinet d’avocats devrait être examinée dans chaque cas ».

        Les lignes directrices de 2014 comprennent une nouvelle ligne directrice 4.3.4, qui identifie comme verte la circonstance dans laquelle « [l’]arbitre serait un conférencier, modérateur ou organisateur dans une ou plusieurs conférences, ou ayant participé à des séminaires ou à des groupes de travail d’une organisation professionnelle, sociale ou de bienfaisance, avec un autre arbitre ou avocat des parties ». (Liste d’applications des lignes directrices de l’IBA relatives aux conflits de 2014, au ¶ 4.3.4.)

        Les lignes directrices de l’IBA relatives aux conflits de 2014 indiquent clairement que l’arbitre n’a pas besoin de divulguer qu’il ou elle « était un conférencier, modérateur ou organisateur dans une ou plusieurs conférences, ou avait participé à des séminaires ou à des groupes de travail d’une organisation professionnelle, sociale ou de bienfaisance, avec un autre arbitre ou avocat des parties ». (Id.) Ici, l’expert a participé à un panel lié au droit du sport ; son lien avec le sujet ne soulève aucune inférence de parti pris ou de partialité et ne signifie pas non plus une relation avec une des parties, une société affiliée des parties, ou l’avocat d’une partie. Si la participation à un panel avec l’avocat des parties ne doit pas être divulguée, il n’y a aucune raison pour croire que la participation à un panel portant sur le même genre de l’arbitrage en question devrait exiger la divulgation.

        Outre l’examen approfondi des lignes directrices recensées par le panel IRP et l’ombudsman (qui sont discutées ci-dessus), le BGC a également examiné les lignes directrices de l’IBA relatives aux conflits dans leur intégralité. Sur la base de la révision, le BGC a conclu, et le Conseil d’administration est d’accord, qu’aucune autre ligne directrice n’est sans doute applicable aux conflits présumés soulevés par le demandeur, et par conséquent, aucune autre ligne directrice ne suggère, encore moins ne prescrit, que les conflits présumés auraient dû être divulgués.

        En vertu de la norme de révision énoncée dans les statuts constitutifs en vigueur lorsque le demandeur a présenté les demandes de réexamen 13-16 et 14-10, la révision du BGC conclurait après avoir évalué si l’ICC a omis de suivre ses processus concernant la nomination de l’expert. Toutefois, conformément à la recommandation du panel IRP et à la résolution du Conseil d’administration, le BGC a examiné la conformité de l’expert avec les lignes directrices de l’IBA relatives aux conflits et, en outre, considéré « si les conflits présumés donnaient lieu à une préoccupation fondée concernant le manque d’indépendance ou d’impartialité de l’Expert au point de porter atteinte à l’intégrité ou à l’impartialité de sa décision ». Pour les raisons détaillées ci-dessus, le contrat de DirecTV et la relation de TyC ne peuvent éventuellement pas soulever une préoccupation fondée quant au manque d’indépendance ou d’impartialité, ou porter atteinte à l’intégrité ou l’impartialité de l’expert. De même, le simple fait que l’expert ait participé à un panel relatif à la question générale du droit du sport ne soulève aucune inférence de parti pris ou de partialité et ne signifie pas non plus une relation avec une des parties, une société affiliée des parties, ou l’avocat d’une partie.

        Le BGC a conclu, pour les raisons évoquées ci-dessus, et le Conseil d’administration est d’accord, que les lignes directrices de l’IBA relatives aux conflits n’ont pas exigé la divulgation par l’expert du contrat de DirecTV, de la relation de TyC, ou de la présentation de l’expert à la conférence, et que les conflits présumés ne donnent lieu à aucune préoccupation fondée concernant l’indépendance ou l’impartialité de l’expert ou l’intégrité ou l’équité de sa décision. Le Conseil d’administration fait remarquer que les demandes 13-16 et 14-10 aux fins du réexamen ont invoqué d’autres motifs en plus des conflits présumés. Ces motifs supplémentaires ne font pas partie de la réévaluation du BGC. Le Conseil d’administration (par le biais du BGC et du NGPC) a évalué au préalable ces motifs supplémentaires dans la décision du BGC sur la demande 13-16 [PDF, 184 KB] et la décision du NGPC sur la demande 14-10. Le Conseil d’administration estime que ses conclusions précédentes sur ces motifs supplémentaires qui ne font pas partie de la recommandation supplémentaire du BGC sur les demandes de réexamen 13-16 et 14-10 [PDF, 365 KB] sont toujours applicables.

        4,3. La lettre du demandeur du 14 juin 2017 ne justifie pas un réexamen.

        La lettre du 14 juin 2017 énonce l’argument suivant : (1) le BGC n’a pas « tenu dument compte » de la déclaration de l’IRP ; (2) le BGC a mal caractérisé le conflit d’intérêts présumé de l’expert ; (3) le BGC a incorrectement appliqué les lignes directrices de l’IBA ; (4) le BGC n’aurait pas dû invoquer le rapport final de l’ombudsman ; et (5) le BGC n’a pas considéré, et l’ICANN n’a pas divulgué, les discussions confidentielles entre l’ICANN et le CIO. (Voir la lettre du 14 juin 2017 [PDF, 903 KB].) Le Conseil d’administration trouve que la lettre du 14 juin 2017 ne contient ni des arguments ni des faits justifiant le réexamen.

        4.3.1. Le BGC a respecté la résolution du Conseil d’administration

        Le Conseil d’administration a enjoint l’ICANN à « suivre les démarches nécessaires » pour mettre en place la recommandation du panel IRP pour que le « Conseil d’administration reconsidère ses décisions sur les demandes de réexamen, dans l’ensemble, appréciant les nouveaux éléments de preuve dans leur intégralité selon la norme applicable aux tiers neutres énoncée dans les lignes directrices de l’IBA relatives aux conflits », ce qui est exactement ce que le BGC a fait. (Résolution 2017.03.16.10) Ni le panel IRP ni le Conseil d’administration n’ont demandé à l’ICANN de conclure que l’expert aurait dû divulguer les conflits présumés soulevés par le demandeur, ou que les lignes directrices de l’IBA relatives aux conflits auraient exigé un résultat particulier.

        Le demandeur cherche à substituer sa compréhension de la déclaration du panel IRP sur le résultat potentiel de l’analyse de l’ICANN avec les instructions de l’ICANN au BCG et au Conseil d’administration d’analyser eux-mêmes les lignes directrices de l’IBA relatives aux conflits. Le demandeur se trompe lorsqu’il affirme que « le panel IRP ait été tout à fait clair [. . .] sur l’existence de cette apparente partialité ». (Lettre du 14 juin 2017 [PDF, 903 KB], p. 2.) Le panel IRP a déclaré, comme le demandeur a fait remarquer, que « [a]u cas où un expert [. . ..] manquerait d’indépendance ou d’impartialité, ou s’il y avait autrement une partialité apparente, il appartient au Conseil d’administration de l’ICANN de réparer cette partialité ». (Id. au 2 ; Déclaration finale de l’IRP, ¶ 7.72.) En outre, le panel IRP a conclu que l’ICANN n’a pas considéré les lignes directrices de l’IBA relatives aux conflits dans sa décision initiale sur les demandes de réexamen 13-16 et 14-10. (Voir la déclaration finale de l’IRP au ¶ 7.88.) Le panel IRP n’a pas conclu que l’ICANN ait appliqué incorrectement les lignes directrices de l’IBA relatives aux conflits.

        4.3.2. Le BGC a abordé les conflits d’intérêts présumés.

        Le demandeur soutient que TyC et DirecTV sont alignées avec, plutôt que défavorables au, CIO, et donc que la décision du BGC d’appliquer les exemples des lignes directrices de l’IBA relatives aux conflits comme si TyC et DirecTV étaient défavorables au CIO était incorrecte. (Voir la lettre du 14 juin 2014 [PDF, 903 KB], p. 2.) En conséquence, comme indiqué dans la recommandation du BGC sur les demandes de réexamen 13-16 et 14-10, que la relation entre le CIO et TyC ou DirecTV ait été alignée ou défavorable, aucun lien entre ces trois entités et SportAccord n’a donné lieu à une partialité apparente. (Voir la Recommandation supplémentaire du BGC sur les demandes de réexamen 13-16 et 14-10 [PDF, 365 KB], p. 16-17.)

        En outre, le Conseil d’administration fait remarquer que le demandeur cite un acte d’accusation d’un mandant de TyC de mai 20152, à l’appui de son argument selon lequel l’expert s’est biaisé lorsqu’il a publié la décision de l’expert en octobre 2013. Les lignes directrices de l’IBA relatives aux conflits sont claires quant aux faits et circonstances opérationnels qui seraient ceux qui étaient présents « à l’époque où [l’expert] a accepté une nomination pour agir comme arbitre et [. . .] tout au long des procédures d’arbitrage ». (Lignes directrices de l’IBA relatives aux conflits, explication de la norme générale 1.) Ils ne sont pas applicables « pendant la période à laquelle la sentence arbitrale peut-être contestée » ou par la suite. (Voir id.) Ce n’est pas clair si l’acte d’accusation est pertinent, mais, même s’il l’était, il a eu lieu bien après la fin de la procédure d’objection et n’est donc pas pertinent à l’analyse des lignes directrices de l’IBA relatives aux conflits. En outre, tel que cela a été abordé dans la décision supplémentaire du BGC sur les demandes de réexamen 13-16 et 14-10, « les activités d’un cabinet de l’arbitre » ne peut pas « constituer automatiquement une source de [. . .] conflit ou un motif de divulgation ». (Recommandation supplémentaire du BGC sur les demandes de réexamen 13-16 et 14-10 [PDF, 365 KB], p. 19-20 ; norme générale des lignes directrices de l’IBA relatives aux conflits 6(a). de 2004). Interpréter les lignes directrices de l’IBA relatives aux conflits comme exigeant la divulgation de relations du cabinet d’avocats aussi faiblement en rapport avec le sujet du litige que la relation de TyC et le contrat de DirecTV le sont avec l’objection imposerait une limite inutile et excessive en ce concernant la capacité des parties d’« utiliser le ou les arbitres de leur choix ». (Id.)

        4.3.3 Le BGC a appliqué correctement les lignes directrices de l’IBA relatives aux conflits.

        Le demandeur affirme incorrectement que le BGC « n’a pas examiné les normes générales des lignes directrices de l’IBA relatives aux conflits ». (Lettre du 14 juin 2017, p. 3.) Le BGC a commencé son analyse des lignes directrices de l’IBA relatives aux conflits avec une discussion des normes générales, y compris l’exigence qu’un expert divulgue « des circonstances ou des faits . . .] pouvant, aux yeux des parties, susciter des doutes quant à l’impartialité ou l’indépendance de l’arbitre ». (Recommandation supplémentaire du BGC sur les demandes de réexamen 13-16 et 14-10 [PDF, 365 KB], p. 13-14 ; lignes directrices de l’IBA relatives aux conflits, explication de la norme générale 1.) Le BGC a également examiné la liste d’applications des lignes directrices, qui vise à fournir « une plus grande cohérence » dans l’application des normes générales. (Voir id.) Le BGC a également considéré la norme générale 6 et l’explication qui l’accompagne, qui portent sur l’analyse des relations du cabinet d’avocats. (Recommandation supplémentaire du BGC sur les demandes de réexamen 13-16 et 14-10 [PDF, 365 KB], p. 19).

        Contrairement à l’affirmation du demandeur, l’analyse du BGC n’était pas « très limitée ». Plutôt, le BGC a appliqué les principes des normes générales et la liste d’applications des lignes directrices pour conclure que les lignes directrices de l’IBA relatives aux conflits n’exigeaient pas à l’expert de divulguer le contrat de DirecTV, la relation de TyC ou la participation de l’expert comme coprésident d’un panel lors de la conférence.

        4.3.4. Les références du BGC au rapport final de l’ombudsman ont été appropriées.

        Le demandeur conteste la référence du BGC au rapport final de l’ombudsman, en avançant que les conclusions de l’ombudsman sont « en désaccord avec celles du panel IRP selon lesquelles le BGC aurait dû examiner les lignes directrices de l’IBA relatives aux conflits ».3 Le demandeur affirme que le BGC « a donné une importance considérable » au rapport final de l’ombudsman, qui « n’était pas pertinent ».

        Le rapport final de l’ombudsman n’est pas incompatible avec les conclusions du panel IRP. Comme le demandeur l’a fait remarquer, le panel IRP a déclaré que le BGC aurait dû tenir compte des lignes directrices de l’IBA relatives aux conflits. En examinant la seconde requête du demandeur, l’ombudsman a examiné les lignes directrices de l’IBA relatives aux conflits et a conclu que celles-ci n’imposent pas la divulgation des conflits prétendus.

        En outre, bien que le BGC ait considéré le rapport final de l’ombudsman, la décision du BGC reposait sur son application des lignes directrices de l’IBA relatives aux conflits aux faits allégués par le demandeur. Il ne s’est pas appuyé sur l’analyse de l’ombudsman pour parvenir à sa conclusion, mais a tout simplement signalé que les résultats de l’analyse étaient conformes à l’analyse de l’ombudsman. Par conséquent, les arguments du demandeur concernant le poids qu’il convient d’accorder au rapport final de l’ombudsman ne sont pas pertinents.

        4.3.5. Les discussions de l’ICANN avec le CIO ne sont pas pertinentes.

        Le demandeur prétend pour la première fois dans la lettre du 14 juin 2017 que l’ICANN a tenu des réunions confidentielles avec le CIO concernant .SPORT. (Voir la lettre du 14 juin 2017 [PDF, 903 KB], p. 4.) Le Conseil d’administration n’est informé d’aucune réunion confidentielle entre l’ICANN et le CIO concernant .SPORT et le demandeur ne cite aucun élément de preuve à l’appui de cette accusation. Il semble que cela a été inclus uniquement pour suggérer que l’ICANN, plutôt que l’expert, avait quelque penchant lié à .SPORT. Toutefois, cette assertion non fondée ne justifie pas un réexamen.

        L’adoption de la recommandation du BAMC n’a pas de répercussions financières sur l’ICANN et n’aura aucune incidence sur la sécurité, la stabilité et la résilience du système des noms de domaine.

        Cette décision relève d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    4. Considération de la recommandation du BGC relative à la demande de réexamen 17-1

      Attendu que, Russ Smith (le demandeur) a déposé la demande de réexamen 17-1 (demande 17-1) contestant les décisions du département de conformité contractuelle de l’ICANN fermant tant sa plainte relative à la convention de service (SLA) du WHOIS, qui a demandé à l’ICANN de contraindre Verisign à produire les données WHOIS historiques pour le nom de domaine directorschoice.com, que sa plainte de suivi exprimant son mécontentement avec le traitement de sa plainte relative à la convention de service du WHOIS sans que les données WHOIS historiques demandées directorschoice.com deviennent disponibles.

      Attendu que, le BGC a déterminé précédemment que la demande est suffisamment fondée et a envoyé la demande à l’ombudsman pour examen conformément au chapitre IV, article 4.2(j)) et (k) des statuts constitutifs de l’ICANN.

      Attendu que, l’Ombudsman s’est récusé sur ce sujet, conformément au chapitre 4 article 4.2(l)(iii) des statuts constitutifs.

      Attendu que, le BGC a soigneusement examiné le bienfondé de la demande 17-1 et tous les documents pertinents, et a recommandé que la demande 17-1 soit rejetée car elle n’établit pas une base appropriée pour le réexamen, et le Conseil d’administration est d’accord.

      Attendu que, le Conseil d’administration a examiné attentivement la réfutation du demandeur et l’addenda à la réfutation de la recommandation du BGC à la demande de réexamen 17-1 et conclut que la réfutation et l’addenda ne fournissent aucun argument supplémentaire ou preuve à l’appui du réexamen.

      Il est résolu (2017.06.24.21) que le Conseil d’administration adopte la Recommandation du BGC sur la demande 17-1 [PDF, 810 KB].

      Fondements de la résolution 2017.06.24.21

      1. Bref récapitulatif

        Le demandeur est le titulaire nommé du nom de domaine directorschoice.com. Le demandeur a déposé une plainte relative à la convention de service du WHOIS demandant essentiellement à l’ICANN de contraindre Verisign à produire les données historiques du WHOIS pour directorschoice.com, ce que, d’après le demandeur, Verisign a refusé de faire. Le demandeur a suggéré que des données WHOIS historiques publiquement disponibles étaient requises en vertu de l’Affirmation d’engagements de 2009 entre le Département du commerce des États-Unis et l’ICANN (AoC), des contrats d’accréditation de bureau d’enregistrement (RAA) et des contrats de registre (RA) de l’ICANN.

        Le département de conformité contractuelle de l’ICANN a examiné la plainte relative à la convention de service du WHOIS et a conclu que : (i) le RAA n’exige pas aux bureaux d’enregistrement de fournir les données WHOIS historiques ; (ii) le RAA n’est pas applicable aux opérateurs de registre (c.-à-d., Verisign) ; et (iii) aucune autre obligation contractuelle de l’ICANN ni aucune politique en vigueur n’exige aux opérateurs de registre de maintenir et de fournir aux titulaires de nom de domaine, ou quelqu’un d’autre, les données historiques du WHOIS. En conséquence, le département de conformité contractuelle a informé le demandeur que l’ICANN n’a pas l’autorité contractuelle d’aborder n’importe quelle « question liée au service client qui ne relève pas du contrat d’accréditation de bureau d’enregistrement (RAA) ou du contrat de registre (RA) et des politiques de l’ICANN » et par la suite a fermé la plainte relative à la convention de service du WHOIS du demandeur.

        Le 16 mars 2017, le demandeur a déposé une autre plainte auprès du département de conformité contractuelle de l’ICANN (Dossier de plainte), exprimant son mécontentement avec le traitement de sa plainte relative à la convention de service du WHOIS et demandant essentiellement à nouveau que l’ICANN fournisse, ou impose à Verisign de fournir, les données historiques du WHOIS pour directorschoice.com. Le département de conformité contractuelle a encore déterminé, et informé le demandeur, que la plainte relative à la convention de service du WHOIS « n’impliquait pas une violation d’une politique ou d’un contrat de l’ICANN ».

        Le demandeur prétend que le réexamen de la décision de l’ICANN de fermer la plainte relative à la convention de service du WHOIS et le dossier de plainte sans action est justifié pour deux raisons. Premièrement, le demandeur affirme à nouveau qu’en ne fournissant pas, ou ne demandant pas à Verisign de fournir, les données WHOIS historiques demandées, l’ICANN a violé les politiques en vigueur, telles que définies dans : (i) l’AoC ;4 et (ii) les termes des contrats de l’ICANN avec les bureaux d’enregistrement et les opérateurs de registre qui, de l’avis du demandeur, exigent à l’ICANN de « permettre l’accès du public aux données whois [sic] sans tenir compte s’il s’agit de données “historiques” ». Deuxièmement, le demandeur affirme que la plainte relative à la convention de service du WHOIS a été fermée « sans prendre en compte des informations importantes » en violation du chapitre IV, article 2(c)(ii) des statuts constitutifs de l’ICANN.

        Le BGC a examiné la demande 17-1 et tous les documents pertinents. Il a recommandé au Conseil d’administration de rejeter la demande 17-1 parce que le réexamen n’est pas fondé en vertu des motifs énoncés dans la Recommandation du BGC sur la demande de réexamen 17-1 [PDF, 810 KB] (la Recommandation du BGC [PDF, 810 KB]), qui ont été examinés et sont incorporés ici.

        OLe 2 juin 2017, le demandeur a présenté une réfutation à la recommandation du BGC (Réfutation [PDF, 28 KB]), conformément au chapitre IV, article 4.2(q) des statuts constitutifs de l’ICANN. Le demandeur indique que : (1) le BGC n’a pas « expliqué[...] la distinction entre les données [WHOIS] actuelles et historiques » dans sa recommandation ; (2) « le personnel de l’ICANN recommande à l’utilisateur [sic] d’acheter des données whois volées au marché noir [sic] lors d’une demande d’accès aux données WHOIS historiques » ; et (3) l’ombudsman ne devrait pas s’être récusé.

        Le 12 juin 2017, le demandeur a présenté un addenda à sa réfutation (Addenda [PDF, 22 KB]), déclarant qu’en attachant la correspondance électronique du demandeur avec l’ICANN à la recommandation, le BGC « a négligé la politique en matière de vie privée publiée [. . .] sans la connaissance ou la permission préalable [du demandeur] ».

        Le Conseil d’administration a examiné la demande 17-1 et tous les documents pertinents, la recommandation du BGC, la réfutation et l’addenda. Le Conseil conclut que ni la demande 17-1, ni la réfutation, ni l’addenda énoncés n’établissent une base justifiant le réexamen.

      2. Les faits

        Le contexte factuel complet est énoncé dans la Recommandation du BGC sur la demande de réexamen 17-1 [PDF, 810 KB], que le Conseil a examinée, et qui est incorporée ici.

        Le 1er juin 2017, le BGC a recommandé que la demande 17-1 soit rejetée au motif qu’elle n’établit pas une base justifiant le réexamen pour les raisons énoncées dans la Recommandation du BGC sur la demande de réexamen 17-1 [PDF, 810 KB], qui sont incorporées ici.

        Le 2 juin 2017, le demandeur a présenté une réfutation de la recommandation du BGC sur la demande de réexamen 17-1 (réfutation), conformément au chapitre IV, article 4.2(q) des statuts constitutifs de l’ICANN, que le Conseil a également examiné.

        Le 12 juin 2017, le demandeur a présenté un addenda à sa réfutation (addenda [PDF, 22 KB]), que le Conseil a également examiné.

      3. Problématiques

        Les problématiques devant être réexaminées sont les suivantes :

        • Si la décision du département de conformité contractuelle de l’ICANN de fermer la plainte relative à la convention de service du WHOIS et au dossier de plainte sans action enfreint une politique de l’ICANN en vigueur ; et
        • Si le département de conformité contractuelle de l’ICANN a fermé la plainte relative à la convention de service du WHOIS sans tenir compte de renseignements importants.
      4. Normes applicables pour évaluer les demandes de réexamen

        Les articles 4.2 (a) et (c) du chapitre 4 des statuts constitutifs de l’ICANN établissent que toute entité peut soumettre une demande « de réexamen ou révision d’une action ou inaction de l’ICANN dans la mesure où elle a subi des effets négatifs par :

        1. au moins une action ou inaction du Conseil d’administration ou du personnel qui serait contraire à la mission, aux engagements, aux valeurs fondamentales et/ou aux politiques établies de l’ICANN ;
        2. au moins une action ou inaction du Conseil d’administration ou du personnel adoptée ou dont l’adoption a été refusée sans tenir compte d’informations importantes, sauf si le requérant n’a pas soumis ces informations, alors qu’il aurait pu le faire, au Conseil d’administration ou au personnel à des fins d’examen au moment où l’action ou l’inaction a été décidée ; ou
        3. au moins une action ou inaction du Conseil d’administration ou du personnel décidée sur la base d’informations importantes fausses ou inexactes.

        (statuts constitutifs de l’ICANN, 1er octobre 2016, Chap. IV, §§ 4.2(a), (c).) Conformément au chapitre IV, article 4.2(k) des statuts constitutifs, si le BGC détermine que la demande est suffisamment fondée, elle est envoyée à l’ombudsman pour examen. (Voir id. au § 4.2(l).) Si l’ombudsman s’abstenait de traiter la question, le BCG examinerait la demande sans sa participation et donnerait une recommandation au Conseil d’administration. (Voir id. au § 4.2(l)(iii).) Le demandeur peut déposer une réfutation à la recommandation du BGC, pourvu que celle-ci : (i) « se limite à remettre en question ou contredire les questions soulevées dans la recommandation définitive du BGC ; et (ii) ne comporte pas de nouvelles données venant étayer un argument présenté dans la demande de réexamen originale du demandeur et que le demandeur aurait pu fournir lorsqu’il a soumis sa demande de réexamen initiale ». (Voir id. au § 4.2(q).) Le refus d’une demande de réexamen sur une action ou inaction de l’ICANN est approprié si le BAMC recommande et le Conseil d’administration détermine que la partie requérante n’a pas satisfait aux critères de réexamen énoncés dans les statuts constitutifs. (Voir id. au § 4.2(e)(vi), (q), (r).)

      5. Analyse et fondements

        Le Conseil d’administration a examiné en profondeur la demande 17-1 et tous les documents y afférents, y compris la recommandation du BGC. Le Conseil conclut que l’analyse énoncée dans la recommandation du BGC semble fondée. Le Conseil a également examiné la réfutation du demandeur à la recommandation du BGC et l’addenda, et il trouve que la réfutation et l’addenda ne présentent ni des arguments ni des faits qui justifient le réexamen.

        5,1. Aucune politique en vigueur n’exige que l’ICANN rende disponibles au public des données WHOIS historiques.

        Le BGC a conclu et le Conseil accorde qu’aucune politique ou procédure n’exige ni à l’organisation ICANN ni au Conseil d’administration de rendre les données WHOIS historiques disponibles publiquement ou d’exiger à l’opérateur de .COM de le faire. En l’occurrence, le demandeur ne peut identifier aucune des politiques ou procédures de l’ICANN qui exige la divulgation de données WHOIS historiques. Le système WHOIS « est le système qui pose la question suivante : qui est (who is) le responsable d’un nom de domaine ou d’une adresse IP ? ». (Voir https://whois.icann.org/en/about-whois.) Le système WHOIS ne pose pas et n’est pas censé poser la question: « qui était » responsable d’un nom de domaine ou d’une adresse IP. Par conséquent, l’outil de recherche WHOIS que l’organisation ICANN inclut dans son site Web permet au public d’identifier le titulaire actuel du nom de domaine — pas tous les titulaires précédents du nom de domaine. Tel que cela est clairement indiqué sur icann.org, « l’ICANN ne produit, ne collecte, ne conserve ni sauvegarde aucun résultat affiché que pour la période temporaire pendant laquelle il est nécessaire de montrer ces résultats en réponse à des requêtes en temps réel ». (https://whois.icann.org/en/history-whois.) Par conséquent, le BGC a conclu, et le Conseil d’administration est d’accord, que l’organisation ICANN n’a violé ni la mission, ni les engagements, ni les valeurs fondamentales, ni aucune politique de l’ICANN établie dans son traitement de la plainte relative à la convention de service du WHOIS ou au dossier de plainte.

        5.1.1 L’AoC a pris fin le 6 janvier 2017, mais n’a pas exigé à l’ICANN de rendre les données WHOIS historiques accessibles au public en aucun cas.

        Le demandeur prétend que l’organisation ICANN a violé la politique établie dans l’AoC lorsqu’elle a fermé sa plainte relative à la convention de service du WHOIS et son dossier de plainte, parce qu’il croit que l’AoC exige que l’organisation ICANN « rende les données disponibles au public [. . .] sans égard au fait qu’il s’agit de données “historiques” ». Le BGC a conclu, et le Conseil d’administration est d’accord, que l’argument du demandeur est sans fondement, pour deux raisons.

        Tout d’abord, l’AoC a pris fin le 6 janvier 2017. (https://www.ntia.doc.gov/files/ntia/publications/ntia-icann_affirmation_of_commitments_01062017.pdf Par conséquent, il ne s’agissait pas d’une « politique de l’ICANN établie » le 9 mars 2017, date à laquelle le département de conformité contractuelle a fermé la plainte relative à la convention de service du WHOIS, ou le 16 mars 2017 quand le dossier de plainte a été fermé. Étant donné que l’AoC n’était pas en vigueur au moment de l’action de l’organisation ICANN, une violation de celle-ci (même si cela avait eu lieu, et ce n’est pas le cas) ne justifierait pas le réexamen.

        Deuxièmement, même si l’AoC était toujours en vigueur, le demandeur perçoit incorrectement les obligations établies dans l’AoC. Dans la partie pertinente, l’AoC de 2009 exige que l’organisation ICANN « mette en place des mesures pour assurer l’accès public, libre et rapide aux informations exactes et complètes du WHOIS, y compris les coordonnées administratives, techniques, de facturation et l’information du contact administratif ». (AoC 2009, § 9.3.1, https://www.icann.org/resources/pages/affirmation-of-commitments-2009-09-30-en.) Alors que le demandeur soutient que ce texte contraint l’organisation ICANN à mettre à disposition les données WHOIS « historiques », une simple lecture de l’AoC confirme que le demandeur interprète faussement le texte en question, car l’AoC ne fait pas du tout référence aux données « historiques ». Au contraire, lorsque l’AoC a abordé les données WHOIS que l’organisation ICANN était censée mettre à disposition, il a fait référence au « titulaire de nom de domaine » au présent, sans faire référence aux titulaires précédents, ce qui atteste que les obligations s’étendaient uniquement aux données WHOIS actuelles. Ainsi, l’AoC n’a jamais exigé à l’organisation ICANN de mettre à disposition des données WHOIS historiques et les réponses du département de la conformité contractuelle à la plainte relative à la convention de service du WHOIS et au dossier de plainte du demandeur n’auraient pas violé une politique en vigueur de l’ICANN, même si l’AoC était encore en vigueur.

        Dans la mesure où les obligations de l’organisation ICANN en vertu de l’AoC ont été incorporées aux statuts constitutifs de l’ICANN, ceux-ci n’exigent pas non plus que l’organisation ICANN rende disponibles des données WHOIS historiques. Au contraire, les statuts font explicitement référence à des données WHOIS « à jour », c’est-à-dire les données actuelles. (Statuts constitutifs de l’ICANN, 1er octobre 2016, Annexes G-1, G-2, https://www.icann.org/resources/pages/governance/bylaws-en/#annexG1 et https://www.icann.org/resources/pages/governance/bylaws-en/#annexG2.) En particulier, une partie de la mission de l’ICANN est de « coordonner [...] l’élaboration et la mise en œuvre des politiques concernant l’enregistrement des noms de domaine de second niveau, » y compris l’élaboration de politiques pour le « maintien et l’accès à des informations précises et à jour concernant les noms enregistrés[,] les serveurs de noms[, et] les enregistrements de noms de domaine ». (Id.) Le demandeur ne maintient pas que l’organisation ICANN a omis de fournir des informations exactes ou à jour sur les noms enregistrés, les serveurs de noms ou les enregistrements de noms de domaine.

        5.1.2. Les contrats de l’ICANN avec les opérateurs de registre et les bureaux d’enregistrement n’exigent pas que l’organisation ICANN rende disponible au public les données WHOIS historiques.

        Le demandeur prétend que les contrats de l’ICANN avec les opérateurs de registre et les bureaux d’enregistrement exigent que l’organisation ICANN « autorise l’accès du public aux données whois [sic] indépendamment du fait qu’il s’agisse de données « historiques ».5 The BGC concluded, and the Board agrees, that the Requestor is incorrect.

        Le contrat de registre avec Verisign pour le registre .COM (RA de .COM) exige que Verisign « exploite un service WHOIS [. . .] fournissant le libre accès du public par requête aux données à jour concernant les enregistrements des noms de domaine et des serveurs de noms ». (RA de .COM, Annexe 5, disponible à https://www.icann.org/resources/pages/appendix-05-2012-12-07-en.) Cela démontre que les obligations prévues dans le RA de .COM s’étendent seulement aux informations d’enregistrement actuelles, pas aux informations historiques. L’annexe 5 du RA de .COM donne un exemple de visualisation du WHOIS qui, encore une fois, montre des informations actuelles et ne fait aucune référence aux données historiques du WHOIS. (Voir id.) Aucune autre partie du RA de .COM (ni aucun autre contrat de registre entre l’ICANN et un opérateur de registre) ne fait allusion aux données WHOIS historiques. Par conséquent, Verisign n’est pas tenu, en vertu du RA de .COM, de fournir les données que le demandeur recherche, et l’organisation ICANN n’avait aucun motif, en vertu du RA de .COM, pour obliger Verisign à fournir ces données.

        Le demandeur soutient également que le RAA contraignait l’ICANN et le bureau d’enregistrement à mettre à disposition les données WHOIS historiques. Le RAA exige que les bureaux d’enregistrement exploitent un service WHOIS qui offre un accès gratuit à, entre autres, « [l]e nom [. . .] du titulaire du nom enregistré » (c’est-à-dire le titulaire de nom de domaine) ; encore une fois, au temps présent. (Voir le RAA 2013, § 3.3.1, https://www.icann.org/en/system/files/files/approved-with-specs-27jun13-en.pdf [PDF, 913 KB] ; voir également le RAA 2013 § 2.1, https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois-accuracy.) En outre, le RAA exige que le bureau d’enregistrement valide les informations relatives au titulaire de nom de domaine uniquement dans la mesure où elles concernent le titulaire actuel ; le bureau d’enregistrement est tenu de conserver cette information pendant « la durée de [l’enregistrement du nom de domaine par le titulaire] ainsi que pendant les deux années qui suivront ». (RAA 2013 § 6.1.1, https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#data-retention.) Le demandeur a enregistré le nom de domaine directorschoice.com le 7 mars 2000. Par conséquent, en supposant que le nom de domaine avait été enregistré précédemment au nom d’un autre titulaire de nom de domaine, en vertu du RAA, le bureau d’enregistrement était uniquement tenu de conserver ces informations jusqu’au 7 mars 2002, au plus tard.

        Le RA de .COM et le RAA n’exigent pas que l’organisation ICANN rende disponibles des données WHOIS. La RA de .COM exige que Verisign le fasse. (RA de .COM, annexe 5, https://www.icann.org/resources/pages/appendix-05-2012-12-07-en.) En vertu du RA actuel de .COM, Verisign n’est tenu de fournir à l’ICANN que les données du WHOIS « résumé ». (Voir id. ; voir également, la politique de transition relative au WHOIS détaillé pour .COM, .NET et .JOBS, https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en ; le Guide d’initiation au WHOIS, https://whois.icann.org/en/primer). Les données WHOIS ne contiennent que les informations suffisantes pour identifier le bureau d’enregistrement parrain, l’état de l’enregistrement, les dates de création et d’expiration de chaque enregistrement, les données du serveur de noms ainsi que la date de la dernière mise à jour de l’enregistrement dans la base de données WHOIS. (Voir la politique de transition relative au WHOIS détaillé pour .COM, .NET et .JOBS, https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en ; le Guide d’initiation au WHOIS, https://whois.icann.org/en/primer). Verisign n’est pas tenu de fournir des données WHOIS détaillées à l’ICANN en vertu du RA de .COM. (Voir le RA de .COM, annexe 5, https://www.icann.org/resources/pages/appendix-05-2012-12-07-en.)

        De même, le RAA exige au bureau d’enregistrement, pas à l’organisation ICANN, de rendre disponibles les données WHOIS référencées. Comme cela a été dit auparavant, pour préciser, « l’ICANN ne produit, ne collecte, ne conserve ni sauvegarde aucun résultat [de recherche WHOIS] affiché que pour la période temporaire pendant laquelle il est nécessaire de montrer ces résultats en réponse à des requêtes en temps réel ». (https://whois.icann.org/en/history-whois.) En d’autres termes, l’organisation ICANN ne maintient pas les données WHOIS et n’est donc pas en mesure d’y donner accès systématiquement. Par conséquent, le BGC a conclu, et le Conseil d’administration est d’accord, que le réexamen n’est pas justifié en raison des obligations que le demandeur tient erronément comme dérivant des contrats avec les registres et les bureaux d’enregistrement.

        5.2 L’organisation ICANN a pris en considération tous les documents d’information.

        La demande semble également alléguer que le département de conformité contractuelle de l’ICANN a fermé la plainte relative à la convention de service du WHOIS « sans prendre en compte des informations importantes » en violation du chapitre IV, article 2(c)(ii) des statuts constitutifs de l’ICANN, dans la mesure où il a avancé que l’organisation ICANN « n’a pas examiné les questions figurant dans » la plainte relative à la convention de service du WHOIS avant de la fermer. Le demandeur n’a soumis aucun élément de preuve établissant — ou même suggérant — que le département de conformité contractuelle n’a pas examiné toutes les informations importantes concernant la plainte relative à la convention de service du WHOIS avant de fournir sa réponse au demandeur. Plutôt, le demandeur semble être insatisfait de la réponse fournie, ce qui ne justifie pas un réexamen.

        Dans le cadre de son évaluation de la demande 17-1, le BGC a demandé si le service de conformité contractuelle de l’ICANN avait pris en compte toutes les informations importantes lors de son évaluation de la plainte relative à la convention de service du WHOIS et du dossier de plainte. Le département de conformité contractuelle de l’ICANN a confirmé avoir examiné toutes les informations fournies par le demandeur.

        5,3. La réfutation et l’addenda ne soulèvent ni d’arguments ni de faits à l’appui d’un réexamen.

        Le Conseil a tenu compte de la réfutation et de l’addenda du demandeur et conclut que le demandeur n’avait invoqué aucun argument supplémentaire ou fait justifiant l’examen.

        La réfutation prétend que : (1) le BGC n’a pas « expliqué[...] la distinction entre les données [WHOIS] actuelles et historiques » dans sa recommandation ; (2) « le personnel de l’ICANN recommande à l’utilisateur [sic] d’acheter des données whois volées au marché noir [sic] lors d’une demande d’accès aux données WHOIS historiques » ; et (3) l’ombudsman ne devrait pas s’être récusé. (La réfutation, https://www.icann.org/en/system/files/files/reconsideration-17-1-smith-requester-rebuttal-bgc-recommendation-02jun17-en.pdf [PDF, 28 KB]).

        Au sujet du premier argument, le Conseil d’administration a examiné la demande 17-1, la recommandation du BGC et la réfutation et conclut que le BGC avait considéré la distinction entre les données WHOIS actuelles et historiques. Le BGC a notamment expliqué que « le système WHOIS est le système qui pose la question suivante : qui est (who is?) le responsable d’un nom de domaine ou d’une adresse IP ? Le système WHOIS n’est pas et n’a jamais été censé poser la question « qui était » responsable d’un nom de domaine ou d’une adresse IP ». (Recommandation du BGC [PDF, 810 KB] à la p. 8.) Le BGC a précisé que l’outil de recherche WHOIS a pour objet d’identifier le titulaire actuel de nom de domaine, pas les titulaires historiques, et que, tel qu’indiqué sur icann.org, « l’ICANN ne produit, ne collecte, ne conserve ni sauvegarde aucun résultat affiché que pour la période temporaire pendant laquelle il est nécessaire de montrer ces résultats en réponse à des requêtes en temps réel ». (Id.) Le BGC a ensuite examiné la mission de l’ICANN, ses engagements, ses valeurs fondamentales et ses politiques en vigueur, et a recommandé qu’aucun de ces documents ou politiques n’exige que l’organisation ICANN rende disponibles au public les données WHOIS historiques, ou que l’opérateur de .COM le fasse. (Id.) Le demandeur peut être en désaccord avec la recommandation du BGC, mais il n’a pas démontré que le BGC n’avait pas considéré si l’organisation ICANN « explique la distinction entre les données [WHOIS] actuelles et historiques ».

        Quant à l’argument du demandeur selon lequel « le personnel de l’ICANN recommande à l’utilisateur [sic] d’acheter des données WHOIS volées au marché noir [sic] lors d’une demande d’accès aux données WHOIS historiques », le demandeur semble faire référence à la réponse du 9 mars 2017 du Centre international d’assistance de l’ICANN (GSC) au demandeur où le GSC disait :

        Malheureusement, l’ICANN ne conserve pas l’historique du WHOIS d’un domaine. Cependant, bon nombre d’entreprises offrent ces informations à titre gratuit. Pour trouver des entreprises qui offrent l’historique WHOIS à titre gratuit, vous pourrez saisir quelques-uns des mots-clés suivants dans un moteur de recherche Web : « WHOIS History Lookup Free » « Domain WHOIS History Free » « Historical WHOIS Free » « Free Domain History Lookup ».

        (Recommandation du BGC [PDF, 810 KB] dans la pièce jointe 3, p. 3.) Alors que le demandeur est apparemment d’avis que les « services de tiers [. . .] piratent et volent effectivement des informations des différentes bases de données whois [sic], » il n’a soumis aucun élément de preuve démontrant que les données WHOIS historiques disponibles en ligne gratuitement sont susceptibles d’être volées. En outre, le Conseil a examiné le message du GSC au demandeur et ne considère pas que le GSC ait recommandé au demandeur d’essayer d’obtenir des données « volées » ; plutôt, le GSC fournissait des informations dans le but d’aider le demandeur à obtenir les informations qu’il cherchait (même si l’organisation ICANN n’était pas tenue de fournir ces données).

        Le Conseil conclut que les allégations du demandeur concernant la récusation de l’ombudsman ne sont pas fondées. L’ombudsman est tenu de se récuser face aux « demandes portant sur des questions pour lesquelles le médiateur a, préalablement au dépôt de la demande de réexamen, pris position dans le cadre de sa fonction d’ombudsman conformément au chapitre 5 des statuts constitutifs, ou impliquant personnellement l’ombudsman d’une façon quelconque ». (Statuts constitutifs de l’ICANN, chapitre IV, article 4.2(I)(iii).) Ici, l’ombudsman s’est récusé conformément à cette exigence. (Voir la réponse de l’ombudsman à la demande 17-1, https://www.icann.org/en/system/files/files/reconsideration-17-1-smith-response-ombudsman-07apr17-en.pdf [PDF, 76 KB].)

        Il est allégué dans l’addenda qu’en joignant la correspondance par courrier électronique entre le demandeur et l’ICANN à la recommandation, le BGC « a négligé la politique en matière de vie privée publiée [. . .] sans la connaissance ou la permission préalable [du demandeur] ». (Addenda [PDF, 22 KB], p. 1) Le demandeur se trompe dans son évaluation de la politique en matière de vie privée de l’ICANN. Selon la politique de l’ICANN en matière de vie privée, « L’ICANN  peut inclure les données personnelles de l’Utilisateur lors de la publication de ses commentaires ou de sa contribution sur le Site Web de l’ICANN pour le bénéfice des tiers ou bien pour se conformer aux principes de l’ICANN en matière de responsabilité et de transparence ».6 Le réexamen est l’un des mécanismes de responsabilité de l’ICANN.7 Conformément au chapitre IV, article 4.2(p) des statuts constitutifs de l’ICANN, le BGC doit agir « sur la base des registres publics écrits, y compris les informations soumises par le demandeur, par le personnel de l’ICANN et par tout tiers » au moment de délivrer sa recommandation au Conseil d’administration. (Statuts constitutifs, chapitre IV, § 4.2(p).) Dans le cadre de l’examen de la demande 17-1, le BGC a évalué la plainte relative à la convention de service du WHOIS et le dossier de plainte, y comprises les communications par courrier électronique entre le demandeur et le GSC de l’ICANN qui ont été annexées au dossier de plainte et qui faisaient partie des allégations du demandeur. Le BGC a obtenu ces documents de l’organisation ICANN car le demandeur ne les a attachés ni à la demande 17-1 ni au supplément à la demande 17-1. Le BGC a donc été tenu, en vertu du chapitre IV, article 4.2(p) des statuts constitutifs, de les placer dans le registre public. La politique en matière de vie privée et les statuts constitutifs de l’ICANN permettent la publication de la plainte relative à la convention de service du WHOIS du demandeur et du dossier de plainte, y compris la communication par courrier électronique entre le demandeur et le GSC de l’ICANN à cet effet. En outre, le Conseil fait remarquer que les informations personnelles du demandeur sur la plainte relative à la convention de service du WHOIS et le dossier de plainte, y compris la communication par courrier électronique entre le demandeur et le GSC de l’ICANN annexée au dossier de la plainte, ont été expurgées avant la publication des pièces jointes à la recommandation du BGC concernant la demande 17-1. Les seules informations personnelles qui n’ont pas été expurgées étaient les informations déjà disponibles au public à travers une recherche WHOIS de directorschoice.com. Par conséquent, il n’y a eu aucune violation de la politique de l’ICANN en matière de vie privée.

        L’adoption de la recommandation du BAMC n’a pas de répercussions financières sur l’ICANN et n’aura aucune incidence sur la sécurité, la stabilité et la résilience du système des noms de domaine.

        Cette décision relève d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    5. Renouvèlement du contrat de registre de .NET

      Attendu que, l’ICANN a lancé une période de consultation publique du 20 avril 2017 au 30 mai 2017 au sujet du contrat de renouvèlement de registre proposé pour le TLD .NET.

      Attendu que, le contrat de renouvèlement de registre de .NET comprend des dispositions nouvelles ou modifiées conformes aux dispositions comparables des contrats de registre de .ORG et .COM.

      Attendu que, le contrat de renouvèlement de registre de .NET comprend de nouvelles dispositions conformes aux dispositions comparables du contrat de registre de base de nouveaux gTLD.

      Attendu que, le forum de consultation publique sur le contrat de renouvèlement de registre proposé s’est achevé le 30 mai 2017, l’ICANN ayant reçu des commentaires de vingt-trois (23) organisations indépendantes et individus. Un résumé et une analyse des commentaires ont été fournis au Conseil d’administration.

      Attendu que, le Conseil a déterminé qu’aucune révision au contrat de renouvèlement de registre de .NET proposé ne sera nécessaire après avoir pris en considération les commentaires.

      Il est résolu (2017.06.24.22) que le renouvèlement du contrat de registre de .NET proposé est approuvé, et le Président-directeur général, ou son représentant, est autorisé à prendre les mesures nécessaires comme cela lui semblera approprié pour conclure et mettre en œuvre ledit contrat.

      Fondements de la résolution 2017.06.24.22

      Pourquoi le Conseil d’administration aborde-t-il cette question maintenant ?

      L’ICANN et Verisign ont conclu un contrat de registre le 1er juillet 1985 pour l’exploitation du domaine de premier niveau .NET. Le contrat de registre de .NET en vigueur expire le 30 juin 2017. Le contrat de renouvèlement de registre proposé a été publié pour consultation publique entre le 20 avril 2017 et le 30 mai 2017. En ce moment, le Conseil d’administration approuve le contrat de renouvèlement de registre proposé pour la poursuite de l’exploitation du TLD .NET par Verisign.

      Quelle est la proposition à l’étude ?

      Le contrat de renouvèlement de registre de .NET proposé, approuvé par le Conseil d’administration, est basé sur le contrat de registre de .NET en vigueur avec des modifications accordées entre l’ICANN et Verisign, et comprend certaines dispositions incorporées aux contrats de registre des gTLD historiques (tels que le contrat de registre de .ORG, daté du 22 aout 2013), ainsi que certaines dispositions du contrat de registre de base des nouveaux gTLD.

      Quelles parties prenantes (ou autres) ont été consultées ?

      Du 20 avril 2017 au 30 mai 2017, l’organisation ICANN a mené une période de consultation publique ouverte concernant l’ensemble des termes du contrat de renouvèlement de registre de .NET proposé. Par la suite, l’organisation ICANN a résumé, analysé et publié un rapport sur les commentaires publics reçus. En outre, l’ICANN a lancé des négociations bilatérales avec l’opérateur de registre pour convenir l’ensemble des termes à inclure dans le contrat de renouvèlement de registre proposé publié pour consultation publique.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      Le forum de consultation publique sur le contrat de renouvèlement de registre de .NET proposé s’est achevé le 30 mai 2017, l’organisation ICANN ayant reçu vingt-trois (23) commentaires. Les commentaires comprenaient les contributions de vingt-trois (23) organisations indépendantes, résumées dans les trois principales catégories énumérées ci-dessous.

      1. Prix des registres (article 7.3) – Bien que l’article 7.3 du contrat de registre n’ait pas changé, beaucoup de commentaires étaient axés sur l’augmentation annuelle autorisée de 10 % des frais d’enregistrement disponible en vertu des termes du contrat de registre de .NET. La plupart s’opposent à l’augmentation des frais disponible tandis qu’un intervenant a déclaré que l’ICANN n’est pas en mesure d’être un « régulateur de prix » et ne s’est pas opposé à l’augmentation de prix dans la mesure où l’augmentation de prix d’un maximum de 10 % annuel reste intacte et ne s’applique pas au contrat de registre de .COM dont le renouvèlement aura lieu en 2018.
      2. Frais de registre versés à l’ICANN (article 7.2) – Les commentaires portaient sur les frais de USD 0,75 que Verisign verse à l’ICANN par enregistrement de domaine .NET et sur les raisons pour lesquelles ils diffèrent de l’USD 0,25 versé par les autres domaines de premier niveau. Les principales préoccupations touchaient le fait qu’il n’était pas juste de laisser le fardeau des couts supplémentaires se répercuter sur les titulaires de nom de domaine, la valeur des frais supplémentaires et la façon dont l’ICANN utilise ces frais. Des demandes ont été présentées, réclamant plus de détails et de responsabilité quant à la manière dont les fonds sont distribués pour soutenir la mission permanente de l’ICANN qui consiste à renforcer la sécurité et la stabilité du DNS et de l’Internet et pour améliorer la participation de la communauté Internet.
      3. Contrat de registre – La communauté s’est déclarée préoccupée du fait que le contrat de registre de .NET contient une clause de renouvèlement présomptive et estime que le contrat devrait être ouvert à un appel d’offres. Les intervenants ont considéré que le renouvèlement présomptif était non concurrentiel du fait qu’un seul opérateur de registre gère les deux TLD ayant les volumes les plus élevés. Comme indiqué dans le récapitulatif et dans l’analyse des commentaires, les dispositions de renouvèlement du contrat de registre de .NET en vigueur sont généralement conformes avec celles de tous les autres contrats de registre de gTLD. Ces dispositions relatives au renouvèlement encouragent les investissements de long terme pour des opérations de TLD solides et cela a été bénéfique pour la communauté grâce à l’exploitation fiable de l’infrastructure du registre. Aux termes du contrat de registre de .NET en vigueur, l’ICANN n’a pas le droit de refuser unilatéralement le renouvèlement du contrat ou de subdiviser les fonctions de registre.
      4. Exclusion de la gestion de la protection des droits – La communauté a été divisée en ce concernant l’exclusion des mécanismes de protection des droits relatifs aux nouveaux gTLD et des sauvegardes dans les gTLD historiques : Certains intervenants se sont exprimés en faveur de l’exclusion de certains mécanismes de protection des droits, tels que le système uniforme de suspension rapide et la procédure de règlement de litiges après délégation relatifs à des marques déposées, et pour l’exclusion des engagements d’intérêt public (c’est-à-dire, des sauvegardes) contenus dans le contrat de registre des nouveaux gTLD, indiquant qu’il ne s’agit pas de politiques consensuelles et que les opérateurs de registre devraient attendre jusqu’à ce qu’une décision finale ait été prise au moyen du processus d’élaboration de politiques (PDP) de l’Organisation de soutien aux extensions génériques (GNSO). D’autres se sont inquiétés de l’exclusion des mécanismes de protection de droits relatifs aux gTLD, faisant valoir que les dispositions ne devraient pas être appliquées uniquement par les opérateurs de registre des nouveaux gTLD.
      5. Processus de négociation – Les intervenants ont fait remarquer qu’alors que le contrat de registre de .NET intègre des avantages techniques et opérationnels importants du contrat de registre des nouveaux gTLD, il ne va pas assez loin et devrait adopter le contrat de registre des nouveaux gTLD. Les intervenants ont suggéré que si .NET ne migre pas au contrat de registre des nouveaux gTLD, il faudrait faire davantage pour harmoniser les dispositions afin d’assurer l’uniformité entre les contrats de registre. En outre, les intervenants ont signalé un manque de transparence dans le processus de négociation entre l’ICANN et Verisign et ont demandé plus d’exposition au processus de négociation avant qu’un contrat de registre ne soit finalisé.

      Quels sont les principaux documents examinés par le Conseil ?

      Dans le cadre de ses délibérations, le Conseil d’administration a examiné plusieurs documents, y compris, mais sans s’y limiter, les documents et supports suivants :

      Quels sont les facteurs que le Conseil d’administration a trouvés significatifs ?

      Le Conseil d’administration a soigneusement examiné les commentaires publics reçus par rapport au contrat de renouvèlement de registre de .NET, ainsi que le résumé et l’analyse de ces commentaires. Le Conseil a également examiné les termes convenus par l’opérateur de registre dans le cadre des négociations bilatérales avec l’organisation ICANN. Le Conseil prend note certes des préoccupations exprimées par certains membres de la communauté au sujet de l’augmentation annuelle de 10 %, mais il reconnait que l’opérateur de registre est autorisé à déterminer les frais pour les enregistrements de domaine de .NET dans le respect du plafonnement des frais prévu dans le contrat de registre de .NET. En outre, le Conseil d’administration croit comprendre que les dispositions actuelles de plafonnement des frais prévues dans les contrats de registre de Verisign, y compris dans le contrat de registre de .NET, ont évolué historiquement pour répondre à divers facteurs de marché en coopération avec des entités au-delà de l’ICANN, y compris le Département du commerce. Au cours des négociations pour le renouvèlement, Verisign n’a pas demandé de modifier les dispositions relatives au plafonnement des frais, les parties n’ont pas négocié ces dispositions et les dispositions demeurent inchangées par rapport au contrat précédent.8 Le plafonnement historique de 10 % était sans doute inclus afin de permettre à l’opérateur de registre d’augmenter les prix pour tenir compte de l’inflation et de toute augmentation des couts/investissements, ainsi que pour prendre en considération toute autre force du marché, mais n’était pas imposé uniquement par l’ICANN.

      Le Conseil d’administration prend également note des préoccupations exprimées par les membres de la communauté concernant la continuité des frais d’enregistrement de USD 0,75 versés à l’ICANN, plus élevés que les USD 0,25 payés par les autres TLD, et appuie l’utilisation de ces fonds pour soutenir la sécurité et la stabilité du DNS et de l’Internet. En outre, le Conseil d’administration encourage l’organisation d’un plus grand nombre d’activités visant à élargir la communauté Internet. Dans ce but, l’ICANN finance des projets tels que le programme de bourses et se prononce en faveur d’efforts accrus pour que l’ICANN soit transparente dans l’utilisation de ces fonds aux fins des activités prévues.

      Alors que le Conseil d’administration reconnait les préoccupations exprimées par certains membres de la communauté concernant l’exclusion du Système uniforme de suspension rapide (URS), de la Procédure de règlement de litiges après délégation (PDDRP) et des Engagements d’intérêt public (PIC) dans le contrat de renouvèlement de registre de .NET, le Conseil signale que l’inclusion de ces dispositions se fonde sur les négociations bilatérales entre l’organisation ICANN et l’opérateur de registre. Le système uniforme de suspension rapide (URS), la procédure de règlement de litiges après délégation (PDDRP) et les engagements d’intérêt public (PIC) n’ont pas été adoptés comme politique de consensus. Par conséquent, l’organisation ICANN n’a pas la capacité de rendre ces dispositions obligatoires pour des TLD autres que les candidats aux nouveaux gTLD qui ont déposé leur candidature au cours de la série de 2012 des nouveaux gTLD. Toutefois, un opérateur de registre historique peut accepter d’adopter ces dispositions au cours des négociations bilatérales, y compris par suite de l’adoption du contrat de registre des nouveaux gTLD. En conséquence, l’approbation par le Conseil d’administration du contrat de renouvèlement de registre de .NET proposé n’établit l’exclusion ni du système uniforme de suspension rapide, ni de la procédure de règlement de litiges après délégation, ni des engagements d’intérêt public au titre des exigences obligatoires pour les TLD historiques. Ces dispositions ne sont adoptées ou annulées qu’au cas par cas suite aux négociations bilatérales.

      Le Conseil d’administration prend note des commentaires qui remettent en question la transparence du processus de négociation visant à renouveler et modifier les contrats de registre historiques ainsi que la façon dont le contrat de renouvèlement de registre de .NET a été établi. Tous les opérateurs de registre ont la capacité de négocier les termes de leur contrat de registre avec l’organisation ICANN, ce qui implique, fondamentalement, des discussions entre les deux parties contractantes, à savoir l’organisation ICANN et l’opérateur de registre concerné. Ce fut le cas de Verisign avec le contrat de renouvèlement de registre de .NET. Le Conseil fait observer que le processus est simple et implique des discussions entre les deux parties jusqu’à ce que le contrat soit conclu. À ce moment-là, l’organisation ICANN invite la communauté à formuler ses commentaires à travers le processus de consultation publique afin d’assurer la transparence et de recueillir l’inestimable contribution de la communauté. Le Conseil d’administration fait également observer que le contrat de renouvèlement de registre de .NET contient de nouvelles dispositions qui exigent que les parties entament des discussions de renouvèlement au moins six mois avant l’expiration du contrat de renouvèlement de registre de .NET, qui devrait donner à la communauté de l’ICANN une idée des délais du renouvèlement.

      Le Conseil d’administration note que le contrat de registre existant pour .NET prévoit un renouvèlement présomptif à son expiration pourvu que certaines conditions soient remplies. Le contrat de renouvèlement de registre de .NET fait l’objet d’une négociation de termes de renouvèlement raisonnablement acceptables pour l’ICANN et pour l’opérateur de registre. Les termes du renouvèlement approuvés par le Conseil résultent des négociations bilatérales exigées dans le contrat de registre de .NET en vigueur, et le maintien de la forme existante du contrat tout en mettant à jour les dispositions afin de les rapprocher du contrat de registre des nouveaux gTLD ne violerait pas la politique de la GNSO en vigueur. Les dispositions adoptées de la nouvelle forme du contrat de registre des nouveaux gTLD offrent des avantages techniques et opérationnels réels, outre les avantages pour les titulaires de noms de domaine et la communauté Internet  l’adoption du format d’entiercement pour les dépôts d’entiercement de données et la BRDA (accès en masse aux données d’enregistrement), l’adoption de la spécification de l’API pour les rapports concernant l’entiercement de données et les spécifications relatives au service d’annuaire de données d’enregistrement (p. ex. le WHOIS).

      Y a-t-il des effets positifs ou négatifs pour la communauté ?

      L’approbation du contrat de renouvèlement de registre de .NET par le Conseil d’administration offre des avantages techniques et opérationnels réels. L’adoption de certaines dispositions du contrat de registre des nouveaux gTLD assurera l’uniformité dans tous les registres, ce qui conduira à un environnement plus prévisible pour les utilisateurs finaux. Par exemple, le fait que le contrat de renouvèlement de registre de .NET exige l’utilisation de bureaux d’enregistrement accrédités ayant signé le contrat d’accréditation de bureaux d’enregistrement fournit de nombreux avantages aux bureaux d’enregistrement et aux titulaires de noms de domaine.

      Y a-t-il des répercussions financières sur l’organisation ICANN (plan stratégique, plan opérationnel, budget), la communauté et/ou le public ?

      Aucun impact financier significatif n’est à prévoir suite à la signature du contrat de renouvèlement de registre de .NET.

      Y a-t-il des implications pour la sécurité, la stabilité ou la résilience du DNS ?

      Le contrat de renouvèlement de registre de .NET n’est pas censé créer des problèmes liés à la sécurité, la stabilité ou la résilience du DNS. Le contrat de renouvellement de registre de .MUSEUM contient des termes destinés à permettre une action plus rapide dans le cas de certaines menaces à la sécurité ou la stabilité du DNS, mais présente aussi d’autres avantages techniques pour assurer la cohérence dans l’ensemble des registres et un environnement plus prévisible pour les utilisateurs finaux.

Publié le 27 juin 2017.


1 Rapport final de l’ombudsman, p. 4, joint comme annexe 1 à la recommandation supplémentaire du BGC sur les demandes 13-16 et 14-10 [PDF, 365 KB], qui est incorporé ici.

2 Le demandeur affirme que l’acte d’accusation est preuve de la partialité de l’expert, parce que le président de TyC est un associé principal au cabinet d’avocats de l’expert et il « serait dommageable pour [l’expert] et pour les importants clients de son cabinet d’aller contre l’intérêt du CIO et de ses associations connexes ». (Lettre du 14 juin 2014, p. 2).

3 Le demandeur indique qu’il ne comprend pas les « circonstances [dans lesquelles] le deuxième rapport a été créé » et qu’il n’a pas reçu une copie du rapport final de l’ombudsman, daté du 25 aout 2014. (Lettre du 14 juin 2017, p. 3-4) Le rapport final de l’ombudsman indique clairement qu’il a été élaboré en réponse à la deuxième plainte du demandeur, déposée à la suite du rejet de la demande 14-10 par le BGC. (Rapport final de l’ombudsman, p. 2-3, figurant comme annexe 1 de la recommandation supplémentaire du BGC concernant les demandes, 13-16, 14-10). Le demandeur a également avancé que le courrier électronique envoyé le 5 mai 2015 à l’ICANN par l’ombudsman, dans lequel ce dernier a écrit qu’il n’avait « pris aucune mesure après l’élaboration du rapport préliminaire » (c’est-à-dire, le courrier électronique de l’ombudsman daté le 31 mars 2014 ) et « plus jamais eu de nouvelles » du demandeur en ce concernant la plainte, démontre que le demandeur n’a jamais déposé une deuxième plainte auprès de l’ombudsman. (Lettre du 14 juin 2017, p. 4.) Toutefois, l’ombudsman répondait à un courrier électronique de l’ICANN qui visait spécifiquement l’examen par l’ombudsman de la plainte soumise par le demandeur le 6 février 2014 et ne concernait pas la seconde plainte. Par conséquent, le courrier électronique du 5 mai 2015 n’est pas lié à la deuxième plainte.

4 L’AoC a pris fin le 6 janvier 2017, mais certaines des exigences pertinentes, telles que l’engagement de l’ICANN de rendre disponibles les données d’enregistrement de nom domaine exactes et à jour, sont énumérées dans les statuts constitutifs de l’ICANN. Voir la Lettre de Stephen D. Crocker, président du Conseil d’administration de l’ICANN, à Lawrence E. Strickling, secrétaire adjoint aux communications et à l’information, Département du commerce des États-Unis, 3 janvier 2017 ; voir aussi la Lettre de Strickling à Crocker, 6 janvier 2017, joignant une copie contresignée de la lettre du 3 janvier (« lettre de résiliation »), disponible à https://www.ntia.doc.gov/files/ntia/publications/ntia-icann_affirmation_of_commitments_01062017.pdf [PDF, 99 KB] ; statuts constitutifs de l’ICANN, 1er octobre 2016, chapitre 1, § 1.1(a)(i) et annexes G-1 et G-2.

5 Demande, § 7, p. 4.

6 Politique en matière de vie privée de l’ICANN, https://www.icann.org/resources/pages/privacy-2012-12-21-en.

7 Responsabilité et transparence, https://www.icann.org/resources/accountability. La politique de l’ICANN en matière de vie privée inclut un lien vers la page Web de l’ICANN consacrée à la responsabilité et la transparence dans la partie qui porte sur l’utilisation des renseignements personnels d’un utilisateur de manière conforme aux principes de responsabilité de l’ICANN. Voir https://www.icann.org/resources/pages/privacy-2012-12-21-en.

8 Avis d’errata : Les fondements de la résolution 2017.06.24.22 ont été mis à jour le 30 juin 2017 afin de corriger une erreur de frappe. En voici le texte original : Au cours des négociations pour le renouvèlement, Verisign n’a pas demandé de modifier les dispositions relatives au plafonnement des frais, les parties n’ont pas négocié ces dispositions et les dispositions demeurent changées par rapport au contrat précédent ».

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."