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:

Ce document a été traduit dans plusieurs langues dans un but purement informatif. Le texte original faisant foi (en anglais) peut être consulté sur : https://www.icann.org/resources/board-material/resolutions-2017-03-16-en

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal de la réunion du Conseil d’administration
    2. Nomination des nouveaux membres du SSAC
    3. Nomination des représentants de l’opérateur du serveur racine F au RSSAC
    4. Contrat de renouvellement de registre de .MOBI
    5. Demande d’approbation du conseil de la GNSO pour que le PDG et le groupe des représentants des bureaux d’enregistrement évaluent des alternatives pour la mise en œuvre de la politique de transfert de noms de domaine entre bureaux d’enregistrement - partie C (IRTP-C)
    6. Approbation des lignes directrices révisées pour la délégation des pouvoirs concernant la PTI
    7. Remerciement aux hôtes locaux de la 58e réunion de l’ICANN
    8. Remerciements à l’attention des partenaires de la 58e réunion de l’ICANN
    9. Remerciements à l’attention des interprètes, du personnel, des organisateurs et des équipes de l’hôtel ayant contribué à la 58e réunion de l’ICANN
  2. Ordre du jour principal :
    1. Révisions de la charte du Comité chargé de l’efficacité organisationnelle (OEC)
    2. Examen de la déclaration finale concernant le processus de révision indépendante au sujet de l’affaire Gulf Cooperation Council v. ICANN
    3. Examen de la déclaration finale concernant le processus de révision indépendante au sujet de l’affaire dot Sport Limited v. ICANN
    4. Approbation de la politique communautaire anti-harcèlement
    5. Divers
      1. Protections pour les identificateurs du mouvement de la Croix-Rouge / Croissant-Rouge dans les gTLD.
      2. Remerciements à Glen de Saint Géry

 

  1. Ordre du jour approuvé :

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

      Il est résolu (2017.03.16.01) que le Conseil d’administration de l’ICANN approuve le procès-verbal de sa réunion ordinaire du 3 février 2017.

    2. Nomination des nouveaux membres 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 Jay Daley et Cristian Hesselman 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 2019.

      Il est résolu (2017.03.16.02) que le Conseil d’administration nomme Jay Daley et Cristian Hesselman 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 2019.

      Fondements de la résolution 2017.03.16.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 technique et de sécurité, fondamentaux pour la sécurité et la stabilité des systèmes de nommage et d’adressage de l’Internet.

      Le fonctionnement continu du SSAC en tant qu’organe compétent dépend de l’ensemble des experts techniques qui consentent à consacrer une partie de leur temps et de leur énergie pour mener à bien la mission du SSAC. Jay Daley est bien connu pour sa longue histoire avec NZRS Ltd et Nominet UK. Il a de vastes connaissances techniques sur tous les aspects des registres de noms de domaine et des opérations de registre, notamment les ccTLD. Il possède un doctorat en informatique. En ce concernant le travail de Christian Hesselman, la sécurité a toujours occupé une place prépondérante. Il apporte son expérience en matière d’opérations de registre de ccTLD (.nl), il travaille avec les données à grande échelle, notamment les données du DNS (y compris l’utilisation conviviale de la confidentialité des données) et contribue avec une expérience significative dans la gestion des équipes techniques.

      Le SSAC croit que Jay Daley et Cristian Hesselman seraient des membres actifs importants au sein du SSAC.

    3. Nomination des représentants de l’opérateur du serveur racine F au RSSAC

      Attendu que, les statuts constitutifs de l’ICANN prévoient la création d’un Comité consultatif du système des serveurs racine (RSSAC) chargé d’adresser à la communauté et au Conseil d’administration de l’ICANN des recommandations sur les questions liées à l’exploitation, l’administration, la sécurité et l’intégrité du système des serveurs racine de l’Internet.

      Attendu que, les statuts constitutifs de l’ICANN exigent que le Conseil d’administration désigne les membres du RSSAC en se fondant sur les recommandations des coprésidents du RSSAC.

      Attendu que, les coprésidents du RSSAC ont recommandé au Conseil de nommer au RSSAC un représentant de l’opérateur du serveur racine F.

      Il est résolu (2017.03.16.03) que le Conseil d’administration nomme au RSSAC le représentant de l’opérateur du serveur racine F, Fred Baker, pour un mandat prenant fin le 31 décembre 2018.

      Fondements de la résolution 2017.03.16.03

      En mai 2013, les opérateurs des serveurs racine (RSO) ont accepté d’être représentés pour la première fois au RSSAC et chacun a proposé un candidat. En juillet 2013, le Conseil d’administration a approuvé ces candidats, dont les mandats sont échelonnés.

      Brian Reid travaille comme représentant de l’opérateur de serveur racine F depuis mars 2016. Le 17 janvier 2017, l’opérateur du serveur racine F, Internet Systems Consortium, a demandé à ce que son représentant Brian Reid soit remplacé par Fred Baker pour le reste du mandat.

      La nomination de ce membre du RSSAC n’est pas censée avoir d’impact financier sur l’ICANN car les ressources nécessaires pour le soutien au RSSAC ont été prévues dans le budget.

      Cette résolution relève d’une fonction administrative et organisationnelle qui ne nécessite aucune consultation publique. La nomination des membres du RSSAC contribue à l’engagement de l’ICANN pour renforcer la sécurité, la stabilité et la résilience du DNS.

    4. Contrat de renouvellement de registre de .MOBI

      Attendu que, l’ICANN a lancé une période de consultation publique du 23 décembre 2016 au 1er février 2017 concernant le contrat de renouvellement de registre proposé pour le TLD .MOBI.

      Attendu que, le contrat de renouvellement de registre proposé pour .MOBI inclut des dispositions modifiées pour adapter le contrat de registre de .MOBI à la forme du contrat de registre des nouveaux gTLD.

      Attendu que, le contrat de renouvellement de registre inclut la première transition d’un domaine de premier niveau communautaire sponsorisé à un domaine de premier niveau standard non sponsorisé, l’ajout de certains mécanismes de protection des droits, les engagements d’intérêt public, la possibilité de publier au préalable les étiquettes à deux caractères réservées sous réserve de certaines exigences et l’incorporation de la même tarification applicable aux opérateurs de registre des nouveaux gTLD.

      Attendu que, le contrat de renouvellement de registre de .MOBI ne reflète déjà plus ni un domaine de premier niveau communautaire sponsorisé ni la transition du TLD .MOBI à un domaine de premier niveau générique standard, non sponsorisé.

      Attendu que, le forum de consultation publique sur le contrat de renouvellement de registre proposé pour .MOBI s’est achevé le 1er février 2017, l’ICANN ayant reçu des commentaires de quatre (4) d’organisations indépendantes. Un résumé et une analyse des commentaires ont été fournis au Conseil.

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

      Il est résolu (2017.03.16.04) que le renouvellement du contrat de registre de .MOBI proposé soit approuvé, et le Président-directeur général, ou son représentant, est autorisé à appliquer ces décisions comme cela lui semblera approprié pour conclure et mettre en œuvre ledit contrat.

      Fondements de la résolution 2017.03.16.02

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

      L’organisation ICANN et Afilias Technologies Limited (l’« opérateur de registre ») ont conclu un contrat de registre le 10 juillet 2005 pour l’opération du domaine de premier niveau .MOBI. Le contrat de registre de .MOBI en vigueur expire le 31 mars 2017. Le contrat de renouvellement de registre proposé a été publié pour consultation publique entre le 23 décembre 2016 et le 1er février 2017. A ce moment-là, le Conseil approuve le contrat de renouvellement de registre .MOBI proposé pour que l’opérateur de registre continue l’exploitation du domaine de premier niveau .MOBI, y compris la transition des opérations du domaine de premier niveau .MOBI historique à un domaine générique de premier niveau utilisant en substance les mêmes conditions offertes aux nouveaux gTLD sous la forme du contrat de registre des nouveaux gTLD.

      Quelle est la proposition à l’étude ?

      Le contrat de renouvellement de registre proposé, approuvé par le Conseil d’administration, comprend des dispositions modifiées pour adapter le contrat à la forme du contrat de registre des nouveaux gTLD. Les modifications comprennent : la mise à jour des spécifications techniques ; l’incorporation des engagements d’intérêt public, y compris l’obligation de n’engager que des bureaux d’enregistrement ayant conclu le contrat d’accréditation de bureaux d’enregistrement (RAA) de 2013 ; et l’exigence de mettre en œuvre d’autres mécanismes de protection des droits, à savoir la Suspension rapide uniforme (URS) et les Procédures de règlement de litiges après délégation (PDDRP).

      Alors que le domaine de premier niveau .MOBI cessera d’être un domaine de premier niveau communautaire sponsorisé, tous les services de registre approuvés dans le contrat de registre du .MOBI historique seront transférés au contrat de renouvellement proposé. Ces services de registre approuvés incluent le langage commun du contenu de la zone TLD, les services de lutte contre les abus, le verrouillage du domaine, le transfert groupé après l’acquisition partielle de portefeuille, le service de consultation du Whois, la recherche du contact du Whois et les noms de domaine internationalisés de second niveau. Les services approuvés pour .MOBI incluent également un délai de grâce de 270 jours consécutifs à la mise en œuvre qui donne à Affilias le temps suffisant pour compléter la transition de ses opérations techniques afin de répondre aux exigences du contrat de renouvellement.

      En ce qui concerne le programme des noms réservés, le nouveau contrat de registre assure à l’opérateur de registre la capacité d’allouer les étiquettes à deux caractères précédemment réservées au second niveau à .MOBI à travers les bureaux d’enregistrement accrédités par l’organisation ICANN sur la base de son processus de mise en œuvre. En outre, l’opérateur de registre peut également libérer les noms à deux caractères précédemment réservés dans la mesure où l’opérateur de registre parvienne à un accord avec le gouvernement et le gestionnaire des codes de pays ou l’agence de maintenance de la norme ISO 3166. L’opérateur de registre peut également proposer la libération de ces noms en fonction de la mise en œuvre de mesures pour éviter la confusion avec les codes pays correspondants.

      En outre, la charte de parrainage figurant dans l’annexe S du contrat de registre .MOBI précédent n’a pas été transférée au contrat de renouvellement de registre de .MOBI. Alors que les chartes préalables de parrainage historiques ont été incluses dans le contrat de registre des nouveaux gTLD sous la spécification 12 (politiques d’enregistrement communautaires), en vertu du contrat de renouvellement proposé, .MOBI ne sera ni un domaine de premier niveau sponsorisé ni un domaine de premier niveau communautaire. L’organisation ICANN a souligné cet important changement dans sa demande de consultation publique et aucun commentaire ou objection n’ont été reçus à cet égard.

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

      Du 23 décembre 2016 au 1er février 2017, l’organisation ICANN a mené une période de consultation publique ouverte concernant l’ensemble des termes du contrat de renouvellement de registre de .MOBI proposé. Par la suite, l’organisation ICANN a résumé, analysé et publié un rapport sur les commentaires reçus du public. En outre, l’organisation 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 renouvellement 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 renouvellement de registre proposé pour .MOBI s’est achevé le 1er février 2017, l’organisation ICANN ayant reçu quatre commentaires. Les commentaires comprenaient les commentaires de quatre organisations indépendantes, résumés dans les trois principales catégories énumérées ci-dessous.

      1. Inclusion des mécanismes de protection des droits et des sauvegardes des nouveaux gTLD dans les gTLD historiques : quelques intervenants ont appuyé l’inclusion de certains mécanismes de protection des droits, comme le Système uniforme de suspension rapide (URS), la Procédure de règlement de litiges après délégation (PDDRP) des marques déposées et des Engagements d’intérêt public (PIC) (c’est-à-dire les sauvegardes) contenus dans le contrat de registre des nouveaux gTLD comme l’exigence d’utiliser des bureaux d’enregistrement en vertu du contrat d’accréditation de bureau d’enregistrement (RAA) 2013. D’autres ont manifesté leur préoccupation du fait d’inclure des mécanismes de protection de droits des nouveaux gTLD dans les contrats historiques. Ils ont affirmé que ces dispositions ne devraient pas être ajoutées suite aux négociations bilatérales concernant le contrat mais que celles-ci devraient être abordées à travers le processus d’élaboration de politiques.
      2. Transition vers une nouvelle tarification : certains intervenants ont suggéré que le personnel de la Division des domaines mondiaux utilise son influence économique dans le contrat de renouvellement de registre proposé pour inciter les opérateurs de registre à accepter des dispositions non économiques du contrat de registre des nouveaux gTLD, tels que ceux mentionnés dans le paragraphe 1 ci-dessus.
      3. Le processus de négociation pour le contrat de renouvellement de registre proposé pour .MOBI et les négociations des contrats de registre gTLD historiques en général : Certains intervenants ont demandé si le processus de négociation pour renouveler et modifier les contrats de registre historiques est suffisamment transparent et comment le contrat de renouvellement a été établi.
        • Autres : Par ailleurs, un des commentaires soumis portait sur le fait que « la date d’approbation de l’ajustement des frais de transaction au niveau de registre » était subordonnée à la décision discrétionnaire de l’organisation ICANN qu’« il ne reste aucune question relative à la conformité sans résoudre ». Toutefois, le contrat de renouvellement de registre proposé pour .MOBI n’inclut pas une telle disposition et il semble que le commentaire faisait référence à une annonce de consultation publique publiée auparavant associée à une modification du contrat pour un gTLD différent.

      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 renouvellement de registre, 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. Alors que le Conseil reconnaît les préoccupations exprimées par certains membres de la communauté concernant l’inclusion 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 renouvellement de registre, le Conseil note que l’inclusion de ces dispositions dépend des négociations bilatérales entre l’organisation ICANN et l’opérateur de registre, où l’opérateur de registre a manifesté son intérêt de renouveler son contrat de registre pour respecter la forme du contrat de registre des nouveaux gTLD.

      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. En conséquence, l’organisation ICANN n’a pas la capacité de déterminer que ces dispositions soient obligatoires pour tous les TLD autres que les nouveaux candidats aux gTLD qui déposent leur candidature au cours de la série 2012 des nouveaux gTLD. Toutefois, un opérateur de registre historique peut convenir d’adopter ces dispositions au cours des négociations bilatérales et suite à l’adoption de la forme du contrat de registre de base des nouveaux gTLD.

      En conséquence, l’approbation par le Conseil d’administration du contrat de renouvellement de registre .MOBI n’établit pas l’ajout 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) comme des exigences obligatoires pour les TLD historiques. Ces dispositions ne sont adoptées qu’au cas par cas suite aux négociations bilatérales.

      Le Conseil d’administration prend note des commentaires mettant en question si le personnel de la Division des domaines mondiaux (GDD) utilise son influence économique dans le contrat de renouvellement de registre proposé, c’est-à-dire la réduction des frais, pour inciter les opérateurs de registre à accepter des dispositions non économiques du contrat de registre des nouveaux gTLD, telles qu’un mécanisme de protection des droits supplémentaire et les engagements d’intérêt public. Le Conseil d’administration fait remarquer que, comme avec les autres conditions du contrat de renouvellement, la réduction des frais est le fruit de négociations bilatérales et d’accords entre l’organisation ICANN et Afilias. La nouvelle tarification mise à jour est la même ayant été utilisée pour le renouvellement préalable des gTLD historiques .CAT, .JOBS, .PRO, .TEL, et .TRAVEL. Le processus de renouvellement des gTLD historiques inclut le personnel de la Division des domaines mondiaux qui évalue l’impact financier sur le budget de l’organisation ICANN. Comme pour d’autres gTLD historiques, cette évaluation a été complétée et le personnel de la Division des domaines mondiaux a conclu que l’impact financier serait à peine négatif. L’effet de la modification des frais sur le budget annuel de l’organisation ICANN a été également examiné dans le cadre de l’évaluation.

      Le Conseil d’administration prend note des commentaires sur la question de savoir si le processus de négociation pour renouveler et modifier les contrats de registre historiques est suffisamment transparent et comment le contrat de renouvellement 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 avec Afilias et le renouvellement du contrat de .MOBI. Le Conseil note 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é à présenter 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 note que le contrat de registre existant pour .MOBI exige un renouvellement présomptif à son expiration pourvu que certaines conditions soient remplies. Le contrat de renouvellement de registre de .MOBI est soumis à la négociation des termes de renouvellement raisonnablement acceptables pour l’organisation ICANN et pour l’opérateur de registre. Les termes du renouvellement approuvés par le Conseil résultent des négociations bilatérales exigées dans le contrat de registre actuel de .MOBI, et la transition vers la nouvelle forme du contrat de registre ne violerait pas la politique de la GNSO en vigueur. Tel que décrit ci-dessous, la nouvelle forme du contrat de registre fournit certains avantages techniques et opérationnels, outre les avantages pour les titulaires de noms de domaine et la communauté Internet, y compris les engagements d’intérêt public, l’exigence d’utiliser des bureaux d’enregistrement ayant signé le contrat d’accréditation de bureau d’enregistrement 2013 et la capacité de l’organisation ICANN de désigner un opérateur de registre provisoire d’urgence dans l’éventualité où les seuils d’urgence pour les services de registre critiques soient atteints.

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

      L’approbation du Conseil d’administration du contrat de renouvellement de registre offre des avantages techniques et opérationnels positifs. En conformité avec le contrat de renouvellement de registre, au cas où un des seuils d’urgence pour les fonctions de registre seraient atteints, l’opérateur de registre accepte que l’organisation ICANN désigne un opérateur de registre provisoire d’urgence pour le registre du TLD, ce qui atténuerait les risques pour la stabilité et la sécurité du système de noms de domaine. Aussi, l’intégration technique de l’opérateur de registre pour se conformer aux dispositions du contrat des nouveaux gTLD permettra au registre d’utiliser des processus automatisés et uniformes, ce qui facilitera l’exploitation du TLD. Dans le cadre du processus de renouvellement, l’organisation ICANN a mené une révision de la conformité contractuelle en vertu du contrat de registre du .MOBI. Il en surgit qu’Afilias est substantiellement en conformité avec les exigences contractuelles qui lui sont applicables.

      Cela aura aussi un impact positif sur les bureaux d’enregistrement et les titulaires de noms de domaine. Le passage à la forme du contrat de registre des nouveaux gTLD assurera la cohérence dans tous les registres, ce qui conduira à un environnement plus prévisible pour les utilisateurs finaux. Le fait que le contrat de renouvellement de registre de .MOBI exige l’utilisation de bureaux d’enregistrement accrédités, ayant signé le contrat d’accréditation de bureau d’enregistrement (RAA) 2013, fournit de nombreux avantages aux bureaux d’enregistrement et aux titulaires de noms de domaine. Le contrat de renouvellement de registre de .MOBI exige également à l’opérateur de registre d’adopter des mécanismes de protection des droits supplémentaires pour protéger les détenteurs de droits et les engagements d’intérêt public qui offrent des avantages aux unités constitutives des représentants de la propriété intellectuelle et au public.

      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 renouvellement de registre de .MOBI. Il convient de noter que suite à l’approbation du contrat de renouvellement de registre, les frais de registre annuels prévus pour l’organisation ICANN auront un impact financier à peine négatif. Ce changement a été pris en compte dans le budget de l’organisation ICANN.

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

      Le contrat de renouvellement de registre de .MOBI n’est pas censé créer des problèmes liés à la sécurité, la stabilité ou la résilience du DNS. En fait, le contrat de renouvellement de registre 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.

    5. Demande d’approbation du conseil de la GNSO pour que le PDG et le groupe des représentants des bureaux d’enregistrement évaluent des alternatives pour la mise en œuvre de la politique de transfert de noms de domaine entre bureaux d’enregistrement - partie C (IRTP-C)

      Attendu que, le 1er décembre 2016 le conseil de l’Organisation de soutien aux extensions génériques (GNSO) a envoyé une lettre [PDF, 109 KB] au Conseil d’administration de l’ICANN (« lettre du conseil de la GNSO ») au sujet des préoccupations quant à la mise en œuvre de la politique de transfert de noms de domaine entre bureaux d’enregistrement (« politique de transfert ») – partie C.

      Attendu que, la lettre du conseil de la GNSO a demandé au Conseil d’administration d’enjoindre l’organisation ICANN à travailler avec le groupe des représentants des bureaux d’enregistrement (RrSG) et d’autres parties intéressées afin d’évaluer les alternatives de mise en œuvre liées à la politique de transfert - partie C.

      Il est résolu (2017.03.16.05), que le Conseil d’administration ordonne au Président-directeur général de l’ICANN, ou son représentant, de travailler avec le groupe des représentants des bureaux d’enregistrement (RrSG) et les autres parties intéressées afin d’évaluer les alternatives de mise en œuvre liées à la politique de transfert- partie C et d’informer le conseil de la GNSO des résultats de la discussion.

      Fondements de la résolution 2017.03.16.05

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

      Le 1er décembre 2016, le conseil de l’Organisation de soutien aux extensions génériques (GNSO) a envoyé une lettre [PDF, 109 KB] au Conseil d’administration de l’ICANN, dans laquelle il a soulevé des préoccupations liées à la mise en œuvre de la politique de transfert - partie C. Le Conseil d’administration s’attaque au problème maintenant parce que la politique de transfert mise à jour a déjà été mise en place, et la politique ne peut pas être modifiée sans l’autorisation du Conseil d’administration.

      Quelle est la proposition à l’étude ?

      Le conseil de la GNSO a envoyé une lettre [PDF, 109 KB] au Conseil d’administration de l’ICANN, dans laquelle il demande au Conseil d’administration de faire ce qui suit : (1) demander à l’organisation ICANN de travailler avec le groupe des représentants des bureaux d’enregistrement et autres parties intéressées afin d’évaluer les alternatives pour adresser les préoccupations relatives à la mise en œuvre, qui pourraient inclure la délégation du traitement de cette question à l’équipe de révision de la mise en œuvre des services d’anonymisation et d’enregistrement fiduciaire, la reconstitution de l’équipe de révision de la mise en œuvre de la politique de transfert - partie C, ou l’emploi d’autres nouveaux mécanismes en conformité avec les principes de politique et de mise en œuvre et des exigences découlant du rapport final des recommandations du groupe de travail sur la politique et la mise en œuvre de la GNSO [PDF 1,53 MB], adopté par le conseil de la GNSO ; et (2) ordonner à l’organisation ICANN de reporter toute application de la conformité du service d’anonymisation et d’enregistrement fiduciaire avec la politique de transfert pour activer / désactiver ces services en attendant de plus amples consultations et déterminations sur cette question.

      Plus précisément, les préoccupations ont trait à la question de savoir si l’ajout ou la suppression d’un service d’anonymisation et d’enregistrement fiduciaire déclenche potentiellement le verrouillage du transfert entre bureaux d’enregistrement de 60 jours décrit dans la politique de transfert mise à jour. Les recommandations de politique ne font aucune mention à propos de l’ajout ou la suppression des services d’anonymisation et d’enregistrement fiduciaire, et à l’époque où la politique a été mise en œuvre, les préjudices actuels et potentiels décrits par le conseil de la GNSO n’ont pas été portés à l’attention de l’organisation ICANN.

      Les demandes du conseil de la GNSO cherchent à discuter de l’ajout ou la suppression des services d’anonymisation et d’enregistrement fiduciaire et des préjudices potentiels associés au verrouillage du transfert entre bureaux d’enregistrement de 60 jours dans la politique de transfert mise à jour.

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

      Ces mises à jour de la politique de transfert ont été discutées avec le conseil de la GNSO, le groupe des représentants des bureaux d’enregistrement et la communauté de l’ICANN lors de multiples séances publiques tenues au cours des réunions de l’ICANN.

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

      En adoptant sa réponse à la lettre du conseil de la GNSO, le Conseil d’administration a examiné divers documents, y compris, mais sans s’y limiter, les documents suivants :

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

      L’adoption de la demande du conseil de la GNSO aura un impact positif sur la communauté parce qu’elle veillera à ce que la communauté puisse continuer à discuter une question n’ayant pas été abordée par le groupe de travail ainsi que les préjudices potentiels que le conseil de la GNSO a décrits au sujet de l’ajout ou la suppression des services d’anonymisation et d’enregistrement fiduciaire dans la politique de transfert.

      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 ?

      Aucun impact financier n’est prévu.

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

      L’approbation de la résolution n’aura pas d’impact sur 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.

    6. Approbation des lignes directrices révisées pour la délégation des pouvoirs concernant la PTI

      Attendu que, le 8 novembre 2016, le Conseil d’administration de l’ICANN a adopté les lignes directrices pour la délégation de pouvoirs afin d’établir clairement les rôles du Conseil d’administration, du PDG et des cadres de direction en matière de délégation des pouvoirs. À cet égard, le Conseil d’administration a signalé que « les lignes directrices seront révisées périodiquement et modifiées de temps à autre à travers une résolution du Conseil d’administration ».

      Attendu que, le Conseil d’administration a examiné comment refléter correctement la relation entre l’organisation ICANN et la filiale de l’ICANN, Identificateurs techniques publics (PTI), en termes des rôles du Conseil d’administration et du PDG de l’ICANN.

      Attendu que, l’identification de la ligne de délégation des pouvoirs dans l’organisation ICANN vis-à-vis de la PTI favorise la transparence et la clarté.

      Il est résolu (2017.03.16.06) que le Conseil d’administration adopte par ces présentes les « lignes directrices de l’ICANN en matière de délégation des pouvoirs » afin de fournir une orientation claire et une clarification des rôles du Conseil d’administration de l’ICANN, du PDG et des cadres supérieurs de l’ICANN (« Lignes directrices »).

      Fondements de la résolution 2017.03.16.06

      Le Conseil d’administration prend actuellement des mesures pour adopter un ensemble de lignes directrices, les « lignes directrices de l’ICANN en matière de délégation des pouvoirs », afin de fournir une plus grande clarté sur les rôles du Conseil d’administration, du PDG et des cadres supérieurs. Comme résolu le 8 novembre 2016, une mise à jour et une modification de ces lignes directrices étaient prévues, et le processus pour une telle modification inclut la résolution du Conseil d’administration.

      Alors que l’ICANN a acquis de l’expérience dans l’opération de sa filiale, Identificateurs techniques publics (PTI), en tant que contractant qui exécute les fonctions IANA au nom de l’ICANN (l’opérateur des fonctions IANA), il y a un besoin continu d’avoir plus de clarté sur la relation entre l’ICANN et la PTI et sur les responsabilités du PDG de l’ICANN quant à l’opération des fonctions IANA. La modification des lignes directrices adoptées aujourd’hui se limite à refléter ce domaine essentiel à la délégation des pouvoirs.

      À travers l’adoption de ces lignes directrices mises à jour, le Conseil d’administration vise à assurer que le Conseil d’administration, le Président-directeur général et les cadres supérieurs continuent de travailler dans le cadre de leur mission. L’approbation des lignes directrices par le Conseil d’administration aura un impact positif sur la communauté, car celles-ci fournissent davantage de transparence et de clarté en ce concernant les rôles et les responsabilités des membres clés de l’organisation ICANN. En outre, elles approfondissent l’obligation redditionnelle envers la communauté en définissant clairement les rôles et les responsabilités.

      Cette décision du Conseil d’administration n’est pas censée avoir de conséquences financières, et aucun problème de sécurité, de stabilité ou de résilience du DNS n’est à prévoir eu égard à l’approbation de ces lignes directrices par le Conseil d’administration.

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

    7. Remerciement aux hôtes locaux de la 58e réunion de l’ICANN

      Le Conseil d’administration souhaite également exprimer sa reconnaissance au ministre Mette Bock, ministre de la Culture, à l’hôte local, à l’Autorité danoise des affaires et au Forum danois de l’Internet.

    8. Remerciements à l’attention des partenaires de la 58e réunion de l’ICANN

      Le Conseil tient à remercier les sponsors suivants : Verisign, Dyn, Knipp Median und Kommunikation GmbH, The Canadian Internet Registration Authority, Afilias plc, Uniregistry, Public Interest Registry, China Internet Network Information Center, Nominet, CentralNic Group PLC, Radix, Dataprovider.

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

      Le Conseil d’administration exprime sa gratitude aux scribes, 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 Bella Center Copenhagen pour avoir prêté ces magnifiques locaux pour l’occasion. Des remerciements spéciaux sont adressés à Maiken Schultz, Directeur commercial international ; Camilla Nevers, gestionnaire de projet, gestion de projets et planification des congrès ; Stine Holmgren, coordonnatrice de congrès, gestion de projets et planification des congrès ; Linda Laugesen, gestionnaire de projet, gestion de projets et planification des congrès ; Simon Jones, gestionnaire de restauration et boissons ; Tsvetana Mazeva-Katsanevakis, superviseur de réservations de groupe, planification et recrutement des congrès ; Camelia Maria Uilecan, coordinatrice de réservations de groupe, planification et recrutement des congrès ; Mads Nielsen, directeur informatique ; et Bart Van Campen du groupe ASP.

  2. Ordre du jour principal :

    1. Révisions de la charte du Comité chargé de l’efficacité organisationnelle (OEC)

      Attendu que, le Comité du Conseil d’administration chargé de l’efficacité organisationnelle est responsable de l’examen et la supervision des politiques, processus et procédures relatives aux révisions organisationnelles de l’ICANN, dont le mandat est établi à l’article 4.4, conformément à sa charte actuelle.

      Attendu que, parallèlement aux processus des révisions organisationnelles et des révisions spécifiques, il y a la possibilité de rationaliser et de fournir une plus grande cohérence à toutes les révisions.

      Attendu que, le Comité du Conseil d’administration chargé de l’efficacité organisationnelle a proposé de modifier sa charte actuelle afin d’élargir ses opérations de surveillance dans le but d’inclure les révisions spécifiques, point sur lequel le Comité de gouvernance du Conseil d’administration est d’accord.

      Il est résolu (2017.03.16.07) que le Conseil d’administration approuve les révisions proposées à la charte du Comité chargé de l’efficacité organisationnelle afin d’élargir son rôle et d’y inclure les révisions spécifiques.

      Fondements de la résolution 2017.03.16.07

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

      Le Conseil aborde cette question parce que la supervision des révisions spécifiques n’a pas été attribuée à un comité spécifique du Conseil d’administration et qu’il est possible de centraliser le contrôle de tous les processus de révision dans un seul comité de l’ICANN, à savoir l’OEC. Il convient de consolider toutes les révisions sous la responsabilité globale de l’OEC pour s’assurer que des normes similaires soient appliquées uniformément dans l’ensemble des révisions.

      Quelle est la proposition à l’étude ?

      Le Conseil d’administration modifie la charte de l’OEC pour inclure la responsabilité de surveiller les révisions spécifiques établie dans l’article 4.6 des statuts constitutifs, ainsi que les références aux statuts modifiés pour correspondre aux statuts constitutifs de l’ICANN entrés en vigueur le 1er octobre 2016.

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

      L’OEC a proposé ce changement et est prêt à assumer ce rôle. Le BGC est tenu d’évaluer les modifications proposées aux chartes et a réaffirmé son soutien à la recommandation. Aucune consultation communautaire n’est requise.

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

      Le Conseil d’administration a examiné les révisions proposées à la charte du Comité chargé de l’efficacité organisationnelle 2015 et les recommandations du Comité de gouvernance du Conseil d’administration (BGC).

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

      Les révisions proposées visent à unifier la responsabilité de surveillance pour les révisions organisationnelles et spécifiques, facilitant ainsi la rationalisation de la supervision du Conseil sur les deux types de révisions. Ce changement dans le contrôle du processus de révision devrait avoir un impact positif sur l’efficacité et l’efficience des révisions organisationnelles et spécifiques et, par extension, fournir à la communauté une plus grande transparence et une meilleure reddition de comptes.

      Y a-t-il des impacts financiers ou des répercussions à prévoir sur l’ICANN (plan stratégique, plan opérationnel et budget); et / ou le public ?

      Les changements proposés n’auront pas d’impact financier ou de conséquences défavorables sur les plans opérationnels et stratégiques de l’ICANN.

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

      Cette décision n’a aucune implication sur la sécurité, la stabilité ou la résilience du DNS.

    2. Examen de la déclaration finale concernant le processus de révision indépendante au sujet de l’affaire Gulf Cooperation Council v. ICANN

      Attendu que, le 24 octobre 2016 l’ICANN a reçu la déclaration finale du processus de révision indépendante (IRP) dans le cadre de l’IRP déposé par Gulf Cooperation Council (GCC) contre l’ICANN (déclaration finale).

      Attendu que, le panel IRP a déclaré que « GCC est la partie gagnante, » et que la décision du Conseil d’administration de l’ICANN à propos de la candidature d’Asia Green concernant le gTLD « .persiangulf » était incompatible avec l’Acte constitutif et les statuts constitutifs de l’ICANN ». (Voir la déclaration finale, p. 45, X.3-4 et p. 44, X.1, ¶¶ 143, 145.)

      Attendu que, le Panel a recommandé que le « Conseil d’administration ne prenne aucune autre mesure concernant la candidature au gTLD « .persiangulf » et, tout spécifiquement, ne signe pas le contrat de registre avec Asia Green, ou toute autre entité, concernant le gTLD « .persiangulf ». (Voir la déclaration finale, p. 44, X.2.)

      Attendu que, après une révision et un examen approfondis de la déclaration finale, tel qu’énoncés plus en détail dans la rubrique « Fondements » ci-dessous, il semble que le Panel pourrait avoir fondé ses conclusions et sa recommandation sur ce qui pourraient être des conclusions non justifiées et / ou des prémisses factuelles erronées, et pourrait ne pas avoir dûment examiné la considération faite par le Conseil d’administration sur des faits et des documents conformes aux intérêts de GCC.

      Attendu que, conformément au chapitre IV, article 3.21 des statuts constitutifs de l’ICANN en vigueur, le Conseil d’administration a pris en considération les déclarations finales.

      Il est résolu (2017.03.16.08) que le Conseil établisse le besoin d’une prise en considération et d’une analyse approfondies de la déclaration finale, et ordonne au Président-directeur général de l’ICANN, ou son représentant, d’effectuer ou de faire effectuer une nouvelle analyse des prémisses factuelles, des conclusions du Panel et de la capacité du Conseil d’administration à accepter certains aspects de la déclaration finale tout en rejetant potentiellement d’autres aspects de ladite déclaration.

      Fondements de la résolution 2017.03.16.08

      Gulf Cooperation Council (GCC) a engagé le 10 septembre 2013 un processus de révision indépendante (IRP) contestant la décision du Comité du programme des nouveaux gTLD (NGPC) disant que « l’ICANN continuera le processus de candidature de [.PERSIANGULF] conformément aux procédures établies dans le [Guide de candidature] ». (Voir la résolution 2013.09.10.NG03 (Annexe 1), disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-09-10-en#2.c.) Le GCC a présenté une objection à la candidature du nom générique de premier niveau (gTLD) .PERSIANGULF présentée par Asia Green IT System Ltd. (Asia Green) en raison de ce que GCC a décrit comme un litige d’affectation de noms de longue date dans lequel les « nations arabes qui limitent avec le golfe préfèrent le nom « golfe arabe » au lieu du nom « golfe persique ». (Voir la demande de l’IRP, ¶ 3, disponible sur https://www.icann.org/en/system/files/files/gcc-irp-request-05dec14-en.pdf [PDF, 2. 44 MB].)

      En 2012, le GCC et certains de ses États membres, ont exprimé leurs inquiétudes à propos de la candidature d’Asia Green à .PERSIANGLUF. Les gouvernements des Émirats Arabes Unis, Oman, Bahreïn et Qatar, ont envoyé des lettres au GAC et à l’ICANN invoquant le système d’alerte précoce du Comité consultatif gouvernemental (GAC) en ce concernant la candidature et disant que l’avis du GAC concernant le gTLD .PERSIANGLUF est approprié. En conséquence, le 20 novembre 2012, conformément aux dispositions du Guide de candidature, le GAC a publié une alerte précoce sur la candidature, faisant valoir que « le nouveau gTLD faisant l’objet de la candidature est problématique et fait référence à un lieu géographique avec [un] nom litigieux » et « qu’il y a un manque de […] participation et de soutien communautaire ». (Voir l’alerte précoce du GAC disponible surhttps://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197754/Persiangulf-AE-55439.pdf [PDF, 93 KB].)

      Par la suite, en décembre 2012, l’objecteur indépendant de l’ICANN (IO), après avoir examiné les préoccupations du GCC, conclut que la candidature n’était pas contraire aux normes juridiques généralement admises en matière de morale et d’ordre public et qu’en conséquence, il n’y avait aucun fondement pour s’y opposer.

      Le 13 mars 2013, le GCC a déposé une objection de la communauté contre la candidature. Alors que l’objection de la communauté du GCC était en attente, le GAC s’est réuni à Beijing, Chine, au cours de la réunion de l’ICANN, en avril 2013. Dans le communiqué de Beijing, le GAC a émis plusieurs types différents d’avis sur les nombreuses candidatures aux gTLD et a informé l’ICANN qu’il voulait poursuivre l’examen de plusieurs candidatures lors sa réunion suivante à Durban, en Afrique du Sud, y compris la candidature pour .PERSIANGULF et a demandé à l’ICANN de ne pas aller au-delà de l’évaluation initiale de ces candidatures jusqu’à ce que l’analyse de la question ait été conclue. (Voir le communiqué de Beijing disponible sur https://www.icann.org/en/system/files/correspondence/gac-to-board-11apr13-en.pdf [PDF, 156 KB].)

      Conformément au Guide de candidature, le NGPC a étudié l’avis du GAC du communiqué de Beijing et, le 4 juin 2013, a adopté un tableau de bord reflétant sa réponse. Le NGPC a accepté la demande du GAC pour un délai supplémentaire afin d’examiner plusieurs autres candidatures, y compris la candidature pour .PERSIANGULF, précisant que « l’ICANN ne procédera pas au-delà de l’évaluation initiale de ces chaînes identifiées » jusqu’à ce que le GAC ait disposé du temps suffisant pour donner son avis sur les candidatures. Le NGPC a également fait remarquer que les objections de la communauté avaient été déposées au sujet de plusieurs de ces candidatures, y compris la candidature pour .PERSIANGULF. (Voir la résolution du NGPC 2013.06.04.NG01 disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-06-04-en.)

      Au cours de la semaine du 13 juillet 2013, le GAC s’est réuni au cours de la réunion publique de l’ICANN à Durban, en Afrique du Sud. Dans le communiqué de Durban, à savoir la déclaration officielle du GAC à l’ICANN suite à la réunion de Durban, le GAC a informé l’ICANN que le GAC « a finalisé l’examen » de la candidature et qu’il « ne présente pas d’objections » au processus de candidature. Autrement dit, le GAC ne fournit effectivement aucun avis au Conseil d’administration au sujet de la candidature de .PERSIANGULF. Par la suite, le 10 septembre 2013, le NGPC s’est réuni pour analyser le communiqué de Durban et a adopté un tableau de bord du NGPC reflétant la réponse du NGPC. (Voir la résolution du NGPC 2013.09.10.NG03 disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-06-04-en.) Dans son tableau de bord qui a été publié le 12 septembre 2013, le NGPC a noté que le GAC « a finalisé l’examen de la chaîne suivante et ne présente pas d’objections à cette procédure : .persiangulf ». En outre, le NGPC a déclaré que « l’ICANN continuera de traiter cette candidature conformément aux procédures établies dans le [Guide de candidature] », mais a noté que l’objection de la communauté du GCC à la candidature demeurait en attente.

      Suite à cela, le 30 octobre 2013, un expert indépendant nommé par la Chambre de commerce internationale (ICC) a déterminé que l’objection de la communauté du GCC à la candidature n’a pas été retenue.

      En novembre 2013, le GAC a approuvé et publié sur son site Internet le procès-verbal de la réunion de Durban dans lequel il a souligné que certains membres du GAC avaient manifesté des inquiétudes concernant la candidature. (Voir les procès-verbaux du GAC de Durban, demande de l’IRP, Annexe 34, disponible sur https://www.icann.org/en/system/files/files/gcc-irp-request-annex-26-05dec14-en.pdf [PDF, 17.7 MB].)

      La demande IRP du GCC, soumise le 5 décembre 2014, visait à obtenir une déclaration disant que la décision du NGPC pour traiter la candidature violait l’Acte constitutif et les statuts constitutifs de l’ICANN et recommandant au Conseil d’administration que l’ICANN ne prenne aucune décision sur le gTLD .PERSIANGULF. (Voir la déclaration finale, ¶65).

      Le 19 octobre 2016, le panel IRP de trois membres (Panel) a publié sa déclaration finale sur le fond de la question, qui a été distribuée entre les parties concernées le 24 octobre 2016 (https://www.icann.org/en/system/files/files/irp-gcc-final-declaration-24oct16-en.pdf [PDF, 2.52 MB]). Le 15 décembre 2016, le panel a publié sa déclaration finale concernant les coûts (https://www.icann.org/en/system/files/files/irp-gcc-final-declaration-costs-15dec16-en.pdf [PDF, 91 KB]). Après examen et discussion, conformément au chapitre IV, article 3.21 des statuts constitutifs de l’ICANN en vigueur, le Conseil d’administration a déterminé que la considération et l’analyse des conclusions et des recommandations du panel (résumées ci-dessous et disponibles sur https://www.icann.org/en/system/files/files/irp-donuts-final-declaration-05may16-en.pdf [PDF, 7.55 MB] s’avèrent nécessaires.

      Le panel IRP a déclaré que le GCC est la partie gagnante et que « la décision du Conseil d’administration de l’ICANN à propos de la candidature d’Asia Green concernant le gTLD « .persiangulf » était incompatible avec l’Acte constitutif et les statuts constitutifs de l’ICANN ». (Voir la déclaration finale, p. 44-45, X.1, X.3.) Le Panel a en outre déclaré que « l’ICANN doit supporter la totalité des coûts du GCC liés au processus IRP » et qu’elle « devra rembourser au GCC, la somme de 107 924,10 USD une fois que le GCC aura démontré avoir payé ces coûts ». (Voir la déclaration finale des coûts, p. 6, V.2.)

      Le Panel a fondé sa déclaration sur la conclusion que le fondement du Conseil d’administration basé sur les dispositions explicites du Module 3.1 du Guide de candidature a été « indûment formaliste et simpliste » (déclaration finale au ¶ 126), et que le Conseil devrait avoir procédé à une enquête plus approfondie du communiqué de Durban qui avait trait à la demande même si l’« avis » du GAC du communiqué de Durban indiquait que le GAC « avait finalisé l’examen » de la candidature et « ne présente pas d’objections » à la poursuite de la candidature. Autrement dit, le GAC ne fournit effectivement aucun avis au Conseil d’administration au sujet de la candidature pour .PERSIANGULF. Le Panel a en outre reconnu que « le GAC a envoyé une missive au Conseil d’administration de l’ICANN qui allait au-delà des trois formes permises pour son avis » (id., au ¶ 127), notant que le GAC n’a pas respecté son principe opérationnel 47 qui « prévoit que le GAC doit travailler sur la base du consensus et « que s’il était impossible de parvenir à un consensus, le président sera chargé de transmettre l’ensemble des opinions exprimées par ses membres au Conseil d’administration de l’ICANN ». (Voir la déclaration finale au ¶ 128 (italiques omises).) Le Panel a en outre reconnu que le GAC n’a pas transmis les « graves préoccupations du GCC concernant l’avis formel au Conseil d’administration de l’ICANN en vertu de la deuxième option d’avis établie dans le module 3.1 du Guide de candidature » – notant que, si cela avait eu lieu « une enquête ultérieure devrait avoir nécessairement été menée, ainsi qu’un dialogue avec le Conseil d’administration ». (Voir la déclaration finale au ¶ 129.)

      Toutefois, le Panel a effectivement estimé que la candidature et l’« avis » du GAC du communiqué de Durban au sujet de la candidature auraient dû recevoir un traitement différent en raison de la sensibilité concernant le litige des noms « Golfe persique » et « Golfe arabe » et parce que « le dossier montre non seulement une sensibilité importante vis-à-vis de la candidature pour « .persiangulf » d’Asia Green mais aussi un désaccord général autour des noms de gTLD géographiques ayant des connotations religieuses ou culturelles ». (Voir la déclaration finale au ¶ 131.) Selon le Panel, le Conseil d’administration aurait dû aller au-delà des processus et procédures énoncés dans le Guide de candidature pour répondre aux avis du GAC, parce que « outre les procès-verbaux de Durban, l’objection de la communauté en attente et la sensibilisation du public sur le litige des noms « Golfe persique » - « Golfe arabe », le Communiqué de Durban lui-même [] contenait une recommandation expresse disant que, pour les prochaines séries, l’ICANN devrait collaborer avec le GAC pour peaufiner le Guide de candidature en ce concernant la protection des termes ayant une importance nationale, culturelle, géographique et religieuse ». (Voir la déclaration finale au ¶ 131.) Le Panel a ajouté que « ces documents et cette connaissance générale auraient pu et auraient dû entrer en jeu, si ce n’est pas à titre des avis suivants du GAC que ce soit dans le cadre de la responsabilité du Conseil d’administration de respecter [sic] la mission et les valeurs fondamentales de l’ICANN ». (Voir la déclaration finale au ¶ 131.)

      En somme, le Panel a déclaré qu’il « n’est pas convaincu du fait que ce n’est pas parce que le GAC n’a pas exprimé les préoccupations du GCC (manifestées en tant que membres du GAC) dans le Communiqué de Durban que le Conseil d’administration n’avait pas besoin de prendre en considération ces préoccupations ». (Voir la déclaration finale au ¶ 131.) Le Panel a ajouté que le Conseil d’administration aurait dû réviser et prendre en considération les préoccupations du membre du GAC manifestées dans les procès-verbaux de la réunion du GAC de Durban (qui ont été publiés par le GAC en novembre 2013 – un mois après la résolution du NGPC du 10 septembre 2013 adoptant l’avis du GAC).

      D’après ces conclusions, le Panel a déclaré que le Conseil d’administration : (i) a manqué à ses obligations de transparence et d’équité (id. au ¶ 143) ; (ii) « n’a pas exercé la diligence raisonnable et n’a pas agi avec précaution même en ayant à sa disposition un nombre raisonnable de faits avant de décider, le 10 septembre 2013, que la candidature de « .persiangulf » poursuive avec le reste de la procédure de candidature » (id., au ¶ 145) (citations et italiques omis) ; et (iii) « n’aurait pas pu exercer un jugement indépendant pour prendre la décision, censée être dans le meilleur intérêt de la société, car ils n’ont pas l’avantage de la diligence raisonnable et de tous les faits nécessaires » (id., au ¶ 145) (citations et italiques omis).

      Le Panel a également déclaré que : (i) « un Panel IRP ne peut pas abuser de [son] indépendance pour substituer sa propre appréciation du bien-fondé de l’action contestée à l’avis du Conseil d’administration, qui a un pouvoir discrétionnaire important » ; et (ii) « un panel IRP n’est pas chargé de contester les décisions du Conseil d’administration mais plutôt « de déterminer que le Conseil d’administration a agi conformément aux dispositions de l’Acte constitutif et des statuts constitutifs de [l’ICANN] ». (Voir la déclaration finale au ¶ 94.)

      En outre, le Panel a recommandé que le « Conseil d’administration de l’ICANN ne prenne aucune autre mesure concernant la candidature au gTLD « .persiangulf » et, tout spécifiquement, ne signe pas le contrat de registre avec Asia Green, ou toute autre entité, concernant le gTLD « .persiangulf ». (Voir la déclaration finale, p. 44, X.2.)

      Comme demandé, le Conseil d’administration a pris en considération les déclarations finales. Comme le Conseil d’administration l’a indiqué précédemment, il prend très au sérieux les résultats de l’un des mécanismes de responsabilité historiques de l’ICANN et n’est pas encore arrivé aux conclusions finales en la matière. En particulier, après avoir procédé à un premier examen des conclusions du Panel, avoir examiné l’information pertinente concernant les préoccupations du GCC et les mandats énoncés dans le Guide de candidature pour répondre à l’avis du GAC, le Conseil d’administration a déterminé que l’examen et l’analyse plus approfondis des prémisses factuelles et des conclusions du Panel s’avèrent nécessaires.

      Le Panel peut ne pas avoir considéré dûment la sensibilisation du Conseil d’administration vis-à-vis des préoccupations du GCC ayant été communiquées à travers des lettres des pays ayant des objections, l’alerte précoce du GAC en 2012 et la réponse du Conseil d’administration au communiqué du GAC de Beijing, acceptant la demande du GAC pour un délai supplémentaire lui permettant d’étudier plusieurs candidatures, y compris celle de .PERSIANGULF. Le Conseil d’administration connaissait et a également examiné les faits suivants : (i) que l’objecteur indépendant a examiné les préoccupations du GCC et a constaté qu’il n’y avait aucun fondement pour s’opposer à la candidature ; (ii) que l’expert nommé par l’ICC a examiné et rejeté l’objection communautaire du GCC ; et (iii) que le GAC n’est pas parvenu à un avis d’objection par consensus ou non consensus quant à la candidature (comme en témoigne le communiqué de Durban). En outre, le Conseil d’administration connaissait bien les politiques du programme des nouveaux gTLD (élaborées avec la participation de la communauté), qui prévoient de multiples sauvegardes pour les noms géographiques et différentes possibilités en vertu desquelles le GCC pouvait faire entendre ses préoccupations (que le GCC a poursuivies mais n’a pas pu faire prévaloir).

      En outre, même si le Panel fait référence au Module 3.1 du Guide de candidature, le Panel peut avoir ignoré le fait que le GAC n’a pas donné un avis au Conseil d’administration nécessitant une enquête ou un dialogue plus approfondis. Le communiqué de Durban a établi sans équivoque que le GAC « ne présente pas d’objections » à la procédure de candidature. De même, le principe opérationnel 46 du GAC (article XII) établit clairement que : « L’avis du GAC au Conseil d’administration de l’ICANN sera communiqué par le président ». En conséquence, les procès-verbaux des réunions du GAC ne constituent pas un avis du GAC. Si le Conseil d’administration adoptait la recommandation du Panel, cela impliquerait que le Conseil devrait traiter la candidature de .PERSIANGULF de manière différente à celle utilisée pour d’autres candidatures ne faisant pas l’objet de l’avis du GAC, conformément au Module 3.1, ce qui serait une violation des statuts constitutifs de l’ICANN.

      Étant données les questions du Conseil d’administration sur les prémisses factuelles et les conclusions issues de ces prémisses, le Conseil d’administration a déterminé qu’il est nécessaire d’étudier davantage la question et ordonne au Président-directeur général de l’ICANN, ou son représentant, d’effectuer ou de faire effectuer une nouvelle analyse des prémisses factuelles, des conclusions du Panel et de la capacité du Conseil d’administration à accepter certains aspects de la déclaration finale tout en rejetant potentiellement d’autres aspects de ladite déclaration.

      Le Conseil d’administration est conscient qu’il est très sérieux d’envisager des options en plus d’adopter une déclaration finale de l’IRP. Toutefois, le Conseil d’administration croit qu’il doit déterminer si le Panel a mal interprété les faits, a mal compris les statuts constitutifs ou a dépassé la portée de l’IRP.

      Le Conseil reconnaît l’importance de cette décision et veut signaler clairement qu’il prend très au sérieux les résultats de tous les mécanismes de responsabilité de l’ICANN, y compris les recommandations non contraignantes. Le Conseil doit également prendre au sérieux les politiques et procédures énoncées dans le Guide de candidature ayant été développées au cours d’années de travail et de contribution de la communauté.

      Cette décision ne devrait pas avoir d’impact financier direct sur l’organisation bien que, dans l’affirmative, cet impact a été envisagé. La révision et l’analyse ultérieure des déclarations finales du Panel n’auront aucune incidence directe sur la sécurité, la stabilité ou 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.

    3. Examen de la déclaration finale concernant le processus de révision indépendante au sujet de l’affaire dot Sport Limited v. ICANN

      Attendu que, la déclaration finale au sujet du processus de révision indépendante (IRP) déposé par dot Sport Limited (dSL) contre l’ICANN (déclaration finale) a été publiée le 31 janvier 2017.

      Attendu que, le panel IRP a déclaré dSL comme étant la partie gagnante et a déclaré que la « décision du Conseil d’administration de l’ICANN a omis de considérer la preuve de parti-pris apparent présentée par l’expert et a été rendue après la détermination de l’expert était incompatible avec l’Acte [constitutif], les statuts constitutifs et / ou le Guide de candidature ». (Déclaration finale [PDF, 518 KB] au ¶ 9.1(a).)

      Attendu que, le panel IRP a déclaré : (i) « que l’ICANN remboursera au demandeur sa part des frais et dépenses correspondant au Panel et à l’ICDR pour un montant de 79 211,64 USD, une fois que le demandeur aura prouvé que ces frais et dépenses ont effectivement été payés » ; et (ii) que chaque partie « sera responsable de ses propres frais et dépenses ». (Déclaration finale [PDF, 518 KB] aux ¶¶ 8.5 et 9.1(c).)

      Attendu que, le Panel a recommandé que le « Conseil d’administration reconsidère ses décisions sur les demandes de réexamen, dans l’ensemble, pesant les nouveaux éléments de preuve dans leur ensemble contre la norme applicable en matière de neutralité énoncée dans les lignes directrices de conflit de l’IBA ». (Déclaration finale [PDF, 518 KB] au ¶ 9.1(b).)

      Attendu que, conformément au chapitre IV, article 3.21 des statuts constitutifs de l’ICANN en vigueur, le Conseil d’administration a pris en considération la déclaration finale.

      Il est résolu (2017.03.16.09) que le Conseil d’administration accepte les aspects suivants de la déclaration finale : (i) « dSL et la partie gagnante de l’IRP dot Sport Limited v. ICANN ; (ii) l’ICANN remboursera à dSL « sa part des frais et dépenses correspondant au Panel et à l’ICDR pour un montant de 79 211,64 USD, une fois que le [dSL] aura prouvé que ces frais et dépenses ont effectivement été payés » ; et (iii) chaque partie « sera responsable de ses propres frais et dépenses ».

      Il est résolu (2017.03.16.10), que le Conseil ordonne au Président-directeur général, ou son représentant, à prendre toutes les mesures nécessaires pour mettre en œuvre la recommandation du Panel IRP disant que le « Conseil d’administration reconsidère ses décisions sur les demandes de réexamen, dans l’ensemble, évaluant les nouveaux éléments de preuve dans leur ensemble vis-à-vis de la norme applicable en matière de neutralité énoncée dans les lignes directrices de conflit de l’IBA » conformément aux statuts constitutifs en vigueur lorsque le Conseil d’administration a rendu ses décisions antérieures sur les demandes de réexamen de dSL.

      Fondements des résolutions 2017.03.16.09 et 2017.03.16.10

      dot Sport Limited (dSL) a engagé un processus de révision indépendante (IRP) contestant la détermination de l’expert qui confirme l’objection de la communauté contre la candidature de dSL par SportAccord et le refus du Conseil d’administration aux deux demandes de réexamen de dSL. Dans les demandes de réexamen et dans l’IRP, dSL a fait valoir que l’expert membre du Panel « n’était pas correctement formé et […] qu’il avait créé une impression raisonnable de partialité ».

      dSL et SportAccord ont tous les deux présenté leur candidature pour l’opération du gTLD .SPORT. Le 13 mars 2013, SportAccord, une organisation qui chapeaute les fédérations sportives internationales et d’autres associations sportives internationales, a déposé une objection de la communauté contre la candidature de dSL (Candidature), affirmant qu’il y avait une « opposition substantielle à la candidature d’une partie importante de la communauté à laquelle la chaîne gTLD peut être explicitement ou implicitement ciblée » (Objection de la communauté).

      Le 20 juin 2013, la Chambre de commerce internationale (ICC) – le fournisseur de règlement de litiges pertinent – a nommé Jonathan P. Taylor comme l’expert pour évaluer l’objection de la communauté de SportAccord. dSL a présenté une objection à la nomination de M. Taylor le 27 juin 2013, au motif que M. Taylor était un avocat spécialisé dans le droit du sport et a noté qu’il avait représenté l’International Rugby Board et avait travaillé pour le Comité international olympique (CIO). Le 25 juillet 2013, l’ICC a décidé ne pas confirmer la nomination de M. Taylor. Le 29 juillet 2013, l’ICC a nommé Me. Guido Santiago Tawil pour qu’il analyse l’objection de la communauté de SportAccord et a informé les parties de la nomination. Me. Santiago Tawil a présenté son CV et rempli une déclaration d’acceptation et de disponibilité et une déclaration d’impartialité et d’indépendance, déclarant qu’il n’avait rien à divulguer et qu’il pourrait être impartial et indépendant. Le travail du Me. Santiago Tawil met l’accent non pas sur le droit du sport, mais sur l’arbitrage international, le droit administratif et la pratique de l’organisme de règlementation. dSL n’a pas présenté d’objection à la nomination du M. Tawil (Expert).

      Le 23 octobre 2013, l’Expert a rendu une décision confirmant l’Objection de la communauté de SportAccord (détermination de l’Expert). Suite à la publication de la décision de l’Expert, dSL a indiqué qu’elle avait découvert que Me. Santiago Tawil avait coprésidé un panel en février 2011, lors d’une conférence (Conférence) intitulée « La quête permettant d’optimiser le processus de règlement de litiges dans les grandes manifestations sportives ».

      Le 2 novembre 2013, dSL a déposé la demande de réexamen 13-16 (Demande 13-16) demandant le réexamen de la décision de l’expert sur les points suivants : (1) l’Expert a appliqué la mauvaise norme pour évaluer les objections de la communauté ; et (ii) l’Expert a omis de divulguer des renseignements importants concernant sa nomination, à savoir sa participation à la Conférence. dLS a fait valoir que la participation de l’Expert à la Conférence avait pour but de créer des connexions au sein de l’industrie sportive organisée, une industrie dont SportAccord faisait partie. Le 8 janvier 2014, le comité de gouvernance du Conseil d’administration de l’ICANN (BGC) a rejeté la Demande 13-16. En ce qui concerne la réclamation de dSL disant que l’expert avait omis de divulguer des renseignements pertinents à sa participation à la conférence, le BGC a noté que, en conformité avec le Guide de candidature, les règles d’expertise de l’ICC régissent les objections à la désignation d’experts, et que dSL n’avait fourni aucun élément de preuve que l’expert, ou l’ICC lui-même, n’avait pas suivi les règles de l’ICC.

      Le 6 février 2014, dSL a déposé une plainte auprès du médiateur de l’ICANN (« Plainte »), réitérant les déclarations que dSL avait soulevées dans la demande 13-16 concernant les conclusions de fond de la décision de l’expert.

      Selon dSL, le 25 mars 2014, elle a découvert que : (i) DirecTV, un client du cabinet de l’expert, a acquis les droits de radiodiffusion pour les Jeux olympiques du CIO le 7 février 2014 ; et (ii) un associé du cabinet juridique de l’expert est le président de Torneos y Competencias S.A. (TyC), une entreprise qui a historiquement obtenu les droits de radiodiffusion des jeux olympiques. dSL a transmis ces informations au médiateur de l’ICANN pour soutenir sa plainte.

      En outre, le 27 mars 2014, dSL a envoyé une lettre à l’ICC au sujet de ces informations, indiquant que, d’après dSL « il y a peu de doutes… sur le fait que Me. Tawil ait fourni des fausses informations [sic] en ce qui concerne sa déclaration d’impartialité » et demandant des précisions supplémentaires quant aux « fondements spécifiques conduisant à la sélection et la nomination de Me. Guido Tawil par le Comité permanent de l’ICC, incluant sans s’y limiter, toute correspondance, procès-verbaux et CV des autres candidats potentiels qui pourraient avoir été suggérés ». Le 29 mars 2014, l’ICC a répondu et a informé dSL que les règles de l’ICC et la Note pratique « établissent un délai spécifique pour les objections » et que le dossier avait été fermé et « ni la [Note pratique] ni les règles de l’ICC justifi[ai]ent la réouverture d’une affaire ou une objection de l’expert après la clôture de l’affaire ».

      Le 31 mars 2014, sans demander le commentaire de l’ICC et exclusivement fondé sur la lettre de l’ICC à dSL, le médiateur a envoyé un courrier électronique à l’ICANN, mettant dSL en copie, au sujet de la plainte de dSL et recommandant que l’objection de la part de la communauté soit reconsidérée par un expert différent. Le 1er avril 2014, l’ICC a envoyé une lettre à l’ICANN exprimant son objection par rapport au fait que le médiateur n’avait jamais contacté l’ICC pour demander son commentaire au sujet de la question de l’expert et que cette dernière « n’a pas eu l’occasion de fournir [au médiateur] des informations pertinentes aux questions soulevées dans la lettre ou pour demander des commentaires additionnels à l’expert concerné ». En réponse, le médiateur a précisé à dSL que son courrier électronique n’était ni un rapport final ni une recommandation et a offert à l’ICC l’opportunité de formuler ses observations.

      Le 2 avril 2014, dSL a déposé la demande de réexamen 14-10 (Demande 14-10) demandant le réexamen de : (i) le rejet de la demande 13-16 par le BGC ; (ii) la décision de l’expert, et (iii) la désignation de l’expert par l’ICC. En conséquence, le médiateur a clôturé la plainte en attente de dSL, car conformément au chapitre V, article 2 des statuts constitutifs de l’ICANN, une plainte déposée auprès du médiateur ne peut pas être poursuivie en parallèle suivant un autre mécanisme de reddition de comptes, comme par exemple une demande de réexamen. Vers le 13 mai 2014, le médiateur a signalé à l’ICANN que dSL avait confirmé qu’elle était parfaitement au courant de cette disposition des statuts constitutifs et avait choisi de poursuivre sa demande 14-10, plutôt que sa plainte auprès du médiateur.

      Le 21 juin 2014 le BGC a recommandé que la demande 14-10 soit refusée en raison du fait que les arguments de dSL concernant les prétendues informations récemment découvertes concernant le conflit d’intérêts de l’expert n’avaient pas été présentées en temps voulu, en vertu des règles de l’ICC, et que le réexamen n’était pas admissible parce que ni le contrat de DirecTV ni la relation avec TyC ne témoignaient d’un conflit d’intérêts suffisant pour justifier la révision. Le 18 juillet 2014 le Comité du programme des nouveaux gTLD de l’ICANN (« NGPC ») a accepté la recommandation du BGC.

      Par la suite, dSL a initié une procédure d’engagement de coopération (CEP) avec l’ICANN et a déposé un IRP. La demande d’IRP de dSL présentée le 24 mars 2015 demandait à ce que l’ICANN soit « obligée à annuler la détermination […] et permettre à la candidature du plaignant de procéder selon ses propres mérites, soit de soumettre l’objection communautaire à une nouvelle analyse par un expert indépendant et impartial ayant reçu une formation appropriée et transparente ».

      Le 31 janvier 2017, le panel IRP composé de trois membres (Panel) a émis sa déclaration finale. Après examen et discussion, conformément au chapitre IV, article 3.21 des statuts constitutifs de l’ICANN en vigueur, le Conseil d’administration a adopté certaines des conclusions du Panel, résumées ci-dessous et disponibles sur https://www.icann.org/en/system/files/files/irp-dot-sport-final-declaration-31jan17-en.pdf [PDF, 518 KB].

      Le panel IRP a déclaré que dSL était la partie gagnante et a déterminé que l’« omission du Conseil d’administration de l’ICANN d’examiner profondément la preuve de partialité apparente de l’expert présentée après la publication de la détermination de l’expert n’était pas conforme à l’Acte [constitutif], aux statuts constitutifs et/ou au Guide de candidature ». (Voir la déclaration finale au ¶ 9.1(a).)

      Plus précisément, le panel IRP a déclaré qu’« il appartient au Conseil d’administration de l’ICANN, à travers le NGPC, le BGC ou le médiateur, de préserver et d’améliorer la fiabilité du système, l’environnement concurrentiel du processus d’enregistrement et la neutralité, l’objectivité, l’intégrité et l’équité du système décisionnel ». (Déclaration finale [PDF, 518 KB] au ¶ 7.71 (italiques à l’original).) Le panel IRP a également indiqué que le « devoir d’impartialité et d’indépendance est permanent ; l’obligation de divulguer toute information qui pourrait, aux yeux d’une des parties, donner lieu à des préoccupations quant à l’impartialité ou l’indépendance de l’expert persiste tout au long du processus de résolution de litiges jusqu’à ce qu’une décision finale soit rendue ». (Déclaration finale [PDF, 518 KB] au ¶ 7.57.) Le panel IRP a en outre indiqué que « [s]i le BGC avait examiné et évalué les nouvelles informations et déterminé qu’elles ne donnaient point 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étermination, et avait rejeté le réexamen sur cette base, cette action ou décision n’aurait pas pu faire l’objet d’une révision ». (Déclaration finale [PDF, 518 KB] au ¶ 7.73.)

      Par la suite, le panel IRP a déclaré que : (i) le Conseil d’administration de l’ICANN « n’a pas suivi ou retransmis la recommandation du médiateur concernant la demande de réexamen, » ce que le panel IRP a considéré un « facteur pertinent aux fins d’examen de ce panel IRP quant à savoir si le Conseil d’administration de l’ICANN a agi conformément à ses documents constitutifs ou non » (Déclaration finale [PDF, 518 KB] au ¶¶ 7.76-7.77)1 ; et (ii) « le BGC n’a pas considéré les lignes directrices d’IBA relatives aux conflits (bien qu’il les accepte dans son argumentation dans ce IRP comme étant la norme de neutralité en vigueur), ou toute autre norme pour les exigences d’indépendance et d’impartialité dans des organes de décision neutres et contraignants » (Déclaration finale [PDF, 518 KB] au ¶ 7.88).

      Le panel IRP a également déclaré que « [l]e BGC a omis de prendre en considération les questions qui découlent de ce que l’expert n’a pas divulgué dans sa déclaration d’impartialité et d’indépendance. Il n’a pas divulgué sa participation au panel qui a donné lieu à la première demande de réexamen, ni toute relation existante avec DirecTV qui ait finalement donné lieu au contrat de DirecTV ou à la relation avec TyC. […] Toutes ou certaines de ces questions pourraient générer une partialité apparente et le fait qu’elles n’aient pas été divulguées ne peut pas être privatif d’un réexamen à ces sujets ». (Déclaration finale [PDF, 518 KB] au ¶ 7.83 (italiques à l’original).)

      Le panel IRP a également déclaré que « le panel IRP est d’avis que pour avoir confirmé l’intégrité du système, conformément à ses valeurs fondamentales, le Conseil d’administration de l’ICANN devait examiner de manière appropriée si les allégations de partialité apparente justifiaient effectivement le réexamen d’une détermination de l’expert. Le Conseil d’administration n’a pas respecté cette exigence et, en conséquence, a contrevenu à ses documents constitutifs ». (Déclaration finale [PDF, 518 KB] au ¶ 7.90.)

      Par la suite, le panel IRP a déclaré que : (i) les frais et les dépenses de l’ICDR et du panel « seront supportés entièrement par l’ICANN » ; (ii) « l’ICANN remboursera au plaignant sa part des frais et des dépenses du panel et de l’ICDR pour un montant de 79 211,64 USD lorsque le plaignant démontrera que ces frais et dépenses ont été payés » ; et (iii) chaque partie « sera responsable de ses propres frais et dépenses ». (Déclaration finale [PDF, 518 KB] aux ¶¶ 8.5 et 9.1(c).)

      Par la suite, le panel IRP a déclaré que : (i) « ni l’acceptation de la détermination des experts par le NGPC ni l’IRP lui-même doivent être entendues comme des processus de recours d’appel ou comme des forums pour la révision de fond des déterminations des experts » ; (ii) « jusqu’à présent il n’existe aucun processus d’appel de ce genre [pour les déterminations des experts] » ; et (iii) « [e]n conséquence, il n’est pas actuellement possible que le plaignant demande ou obtienne une révision de fond de la décision des experts ». (Déclaration finale [PDF, 518 KB] aux ¶ 7.49-7.50.)

      Le panel IRP a recommandé que le « Conseil d’administration reconsidère ses décisions sur les demandes de réexamen, dans l’ensemble, évaluant l’ensemble des nouveaux éléments de preuve vis-à-vis de la norme applicable en matière de neutralité tel que définie dans les lignes directrices d’IBA relatives aux conflits ». (Déclaration finale [PDF, 518 KB] au ¶ 9.1(b).)2

      Comme demandé, le Conseil d’administration a pris en considération la déclaration finale. Comme le Conseil d’administration l’a indiqué précédemment, il prend très au sérieux les résultats de l’un des mécanismes de responsabilité historiques de l’ICANN. Le Conseil note que la portée des demandes de réexamen pertinentes se limitait à déterminer si les politiques ou les processus établis avaient été suivis (en l’occurrence, par des fournisseurs tiers) au niveau d’une révision de fond de l’allégation d’impartialité sous-jacente. En conséquence, et pour les raisons décrites dans cette résolution et ces fondements, le Conseil d’administration a accepté la déclaration finale du Panel telle qu’indiquée ci-dessus. Au moment de la mise en œuvre de la recommandation du panel IRP, les demandes de réexamen de dSL seront réexaminées en conformité avec les statuts constitutifs en vigueur au moment auquel le Conseil d’administration a formulé ses déterminations précédentes sur les demandes de réexamen de dSL, vu que ces statuts constitutifs étaient valides lorsque le Conseil d’administration (via le BGC et le NGPC, respectivement) a formulé les déterminations remises en cause dans l’IRP.

      Cette décision ne devrait pas avoir d’impact financier direct sur l’organisation bien que, dans l’affirmative, cet impact a été envisagé. L’adoption de la déclaration finale du Panel n’aura aucune incidence sur la sécurité, la stabilité ou 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.

    4. Approbation de la politique communautaire anti-harcèlement

      Attendu que, pendant et après l’ICANN55 la question du comportement réciproque de certains membres de la communauté a été soulevée lors de séances et de listes diverses, et que le Conseil d’administration a accepté d’aborder cette question.

      Attendu que, entre autres, le Conseil d’administration a approuvé les normes de conduite requises de l’ICANN révisées et a ordonné au « Président-directeur général ou ses représentants d’engager un expert . pour aider à élaborer une politique/procédure communautaire anti-harcèlement à suivre lors des réunions publiques de l’ICANN, qui pourrait inclure des éléments tels que le traitement des plaintes et des processus de résolution et d’exécution ». (Résolution 2016.05.15.05)

      Attendu que, le Conseil a autorisé la publication pour consultation publique d’une politique anti-harcèlement communautaire de l’ICANN proposée (Politique) pour l’examen et la participation de la communauté.

      Attendu que, tous les commentaires reçus au cours de la période de consultation publique étaient généralement favorables à la politique anti-harcèlement communautaire proposée.

      Attendu que, quelques commentaires demandaient que des améliorations soient apportées à la politique et que certains posaient des questions concernant le rôle du médiateur dans l’évaluation des plaintes déposées en vertu de la politique anti-harcèlement communautaire.

      Il est résolu (2017.03.16.11) que le Conseil d’administration adopte la politique anti-harcèlement communautaire révisée pour répondre à certaines questions soulevées au cours de la période de consultation publique.

      Il est résolu (2017.03.16.12) que le Conseil d’administration ordonne au Président-directeur général, ou son représentant, de (1) s’assurer que l’Organisation continue de contrôler si le bureau du médiateur est l’endroit approprié pour que les membres de la communauté déposent leurs plaintes en vertu de la politique anti-harcèlement communautaire et de réviser la politique chaque année pour évaluer des améliorations futures, en fonction des besoins ; (2) mettre à la disposition de la communauté le département des ressources humaines de l’ICANN pour aider au cas où il y aurait des plaintes dans lesquelles le plaignant aurait indiqué une préférence de communiquer avec une personne d’un sexe différent que le médiateur en fonctions.

      Fondements des résolutions 2017.03.16.11 et 2017.03.16.12

      Pendant et après l’ICANN55 la question du comportement réciproque de certains membres de la communauté a été soulevée lors de séances et de listes diverses, et le Conseil d’administration a accepté d’aborder cette question. En réponse, le Conseil d’administration a approuvé les normes de conduite requises de l’ICANN révisées et a ordonné au « Président-directeur général, ou son représentant, d’engager un expert…pour aider à élaborer une politique/procédure communautaire anti-harcèlement à suivre lors des réunions publiques de l’ICANN, qui pourrait inclure des éléments tels que le traitement des plaintes et des processus de résolution et d’exécution ». (Résolution 2016.05.15.05)

      En novembre 2016, le Conseil d’administration a autorisé la publication pour consultation publique de la politique anti-harcèlement communautaire de l’ICANN proposée (Politique) [PDF, 72 KB]. La politique définit comment les participants de la communauté de l’ICANN sont censés se comporter lorsqu’ils participent aux processus multipartites de l’ICANN. Elle a été créée suite à la consultation avec des experts et après avoir examiné les commentaires publics reçus au sujet des normes de conduite requises adoptées au préalable. Tel que cela a été dit en réponse aux commentaires reçus sur les révisions proposées au normes de conduite requises, l’étape suivante prévue consistait à élaborer et publier pour consultation publique une politique plus détaillée et une procédure de plainte. La politique définit comment les participants de la communauté de l’ICANN sont censés se comporter lorsqu’ils participent aux processus multipartites de l’ICANN, ainsi que les procédures de plainte et de traitement lorsque les membres de la communauté sentent que quelqu’un a manqué à la politique.

      Quatorze commentaires, examinés dans leur totalité para le Conseil d’administration, ont été présentés au cours de la période de consultation publique. En outre, après la clôture de la période de consultation publique, l’ICANN a été informée que le « Centre for Internet and Society » (CIS) avait tenté de soumettre un commentaire au cours de la période de consultation publique, mais n’avait pas réussi. Le commentaire du CIS a été présenté au Conseil d’administration pour son examen. Dans l’ensemble, les commentaires célébraient l’élaboration de la politique. Plusieurs organisations et individus ont proposé d’inclure une déclaration de mission. Certains intervenants ont suggéré que la politique devait indiquer clairement que la définition du harcèlement comprend des comportements non consensuels importuns, particulièrement compte tenu du fait que la pertinence du comportement peut varier en fonction des normes sociales. Certains intervenants ont indiqué que le bureau du médiateur ne devrait pas être chargé d’évaluer des plaintes portées en vertu de la politique parce qu’il semblerait que cela octroie trop de pouvoir au bureau du médiateur.

      Comme toujours, le Conseil d’administration remercie et apprécie les opinions des intervenants au sujet de la terminologie utilisée dans la politique. De même, le Conseil reconnaît et apprécie les questions soulevées sur le fait de savoir si le bureau du médiateur est le plus approprié pour traiter les plaintes formulées en vertu de la politique.

      À partir des commentaires reçus, l’organisation a fait quelques révisions de terminologie pour adresser un bon nombre de commentaires. Celles-ci sont énoncées dans la version préliminaire de la politique avec le suivi des modifications, jointe à ces présentes comme pièce de référence. En ce qui concerne les commentaires relatifs au bureau du médiateur, le Conseil d’administration convient que ces commentaires méritent un examen plus approfondi. Toutefois, le Conseil craint également que le développement d’un autre mécanisme ou structure pour traiter les plaintes portées en vertu de la politique retarderait l’adoption de cette importante politique. En conséquence, le Conseil a décidé d’adopter la politique révisée, mais d’ordonner à l’Organisation d’évaluer en profondeur les commentaires concernant le bureau du médiateur et de contrôler tout problème qui pouvant survenir suite au recours au médiateur à cette fin.

      Dans le cadre de ce processus d’évaluation supplémentaire, le Conseil d’administration tient à souligner que le bureau du médiateur est faculté pour traiter les plaintes qui pourraient être déposées en vertu de la politique. Comme indiqué dans le chapitre IV, article 5.2 des statuts constitutifs,

      la fonction principale du médiateur consistera à fournir une évaluation interne indépendante des plaintes déposées par des membres de la communauté de l’ICANN qui estimeront avoir été injustement traités par le personnel de l’ICANN, le Conseil d’administration ou un organe constitutif de l’ICANN. Le médiateur agira objectivement en faveur de l’équité et cherchera à évaluer et, si possible, à résoudre les plaintes relatives à un traitement injuste ou inapproprié de la part du personnel de l’ICANN, du Conseil d’administration ou des organes constitutifs de l’ICANN, en éclaircissant les problèmes et en utilisant des outils de règlement de litiges tels que la négociation, la facilitation et les « navettes diplomatiques » afin d’obtenir des résultats.

      (Statuts constitutifs, chap. 5, paragraphe 5.2, https://www.icann.org/resources/pages/governance/bylaws-en/#article5.) Compte tenu de ce qui précède, il semble que le traitement des plaintes de la communauté sur la façon dont ils sont traités par d’autres membres de la communauté est directement en ligne avec la fonction que le bureau du médiateur est censé desservir en vertu des statuts constitutifs.

      Néanmoins, le Conseil d’administration prend au sérieux les commentaires reçus au sujet du bureau du médiateur. En conséquence, le Conseil d’administration a ordonné au Président-directeur général, ou à son représentant, de (1) s’assurer que l’Organisation continue de contrôler si le bureau du médiateur est l’endroit approprié pour que les membres de la communauté déposent leurs plaintes en vertu de la politique et de réviser la politique chaque année pour évaluer des améliorations futures, en fonction des besoins.

      Dans le cadre de la mise en œuvre de la politique, l’ICANN mènera une campagne de formation et de sensibilisation adressée à la communauté.

      Le Conseil d’administration fait également remarquer que, bien que la politique s’applique aux participants de la communauté de l’ICANN, le Conseil d’administration reconnaît que les personnes qui travaillent pour l’Organisation doivent être libres de harcèlement et que l’Organisation a une politique interne anti-harcèlement en vigueur.

      Cette décision n’aura aucune répercussion financière sur l’organisation et aucun impact direct sur la sécurité, la stabilité et la résilience du DNS.

      Il s’agit d’une mesure administrative organisationnelle ne nécessitant pas, à ce stade, de consultation publique car la politique sous-jacente a déjà fait l’objet d’une consultation publique.

    5. Divers

      1. Protections pour les identificateurs du mouvement de la Croix-Rouge / Croissant-Rouge dans les gTLD.

        Attendu que, à l’ICANN57 à Hyderabad, le Conseil d’administration a proposé que le GAC et la GNSO s’engagent dans une discussion dirigée de bonne foi pour tenter de résoudre les incohérences en suspens entre l’avis de politiques publiques du GAC et les recommandations de politique consensuelles de la GNSO concernant la protection au second niveau dans tous les gTLD pour les identificateurs (noms et acronymes) des organisations internationales gouvernementales (OIG) et des organisations internationales non-gouvernementales (OING). Cela inclut certains identificateurs du mouvement de la Croix-Rouge Internationale et du Croissant-Rouge (dénommés « identificateurs de niveau 2 » dans le groupe de travail sur le processus d’élaboration de politiques (PDP) Rapport final sur la protection des identificateurs des OIG et OING dans tous les gTLD [PDF, 644 KB]).

        Attendu que, le Conseil d’administration a reconnu que tout résultat d’un dialogue entre les parties concernées devrait être conditionné et serait réexaminé selon les processus internes propres du GAC et de la GNSO.

        Attendu que, des représentants du GAC et de la GNSO se sont engagés dans une discussion facilitée lors de l’ICANN58 à Copenhague pour discuter des protections pour les identificateurs du mouvement de la Croix-Rouge Internationale et du Croissant-Rouge (Recommandation 5) comprises dans la Section 3.1. du rapport final du groupe de travail consacré au PDP.

        Attendu que, le point de départ pour la discussion facilitée était un énoncé du problème et des documents d’information examinés par les parties concernées (https://community.icann.org/x/hIPRAw).

        Attendu que, au cours des discussions facilitées, les parties intéressées ont examiné les questions suivantes :

        (1) le fondement du GAC pour demander des mesures de protection permanentes pour les identificateurs du mouvement international de la Croix-Rouge et du Croissant-Rouge et ses composantes respectives (y compris les 190 filiales nationales de la Croix-Rouge et du Croissant-Rouge et les deux organisations internationales du mouvement – le Comité International de la Croix-Rouge et la Fédération internationale de la Croix-Rouge et du Croissant-Rouge) repose sur la protection des désignations « Croix-Rouge » , « Croissant-Rouge », « Lion et soleil rouges » et « Cristal-Rouge » en vertu des lois en vigueur dans les juridictions nationales multiples ; et sur les considérations de politiques publiques mondiales en matière de protection des identificateurs des organismes respectifs de la Croix-Rouge et du Croissant-Rouge de formes d’abus dans le système des noms de domaine, notamment la fraude et le détournement de fonds en cas de crise humanitaire.

        (2) la liste des noms des filiales nationales de la Croix-Rouge et du Croissant-Rouge présentée pour protection est limitée et comprend les noms des 190 filiales nationales reconnues au sein du mouvement international de la Croix-Rouge et du Croissant-Rouge – le Mouvement – en anglais et dans la ou les langue(s) et script(s) national(aux) officiel(s) de chaque filiale nationale.

        Le nombre de filiales nationales (voir la liste officielle des filiales nationales à http://www.ifrc.org/Docs/ExcelExport/NS_Directory.pdf [PDF, 657 KB]) est limité et ne peut augmenter que suite à la reconnaissance future au sein du mouvement de nouvelles filiales nationales (un événement qui doit encore faire l’objet d’un processus rigoureux et de conditions strictes définies dans les statuts du mouvement). Selon le principe fondamental de l’unité, il ne peut exister qu’une Croix-Rouge, un Croissant-Rouge ou un Cristal-Rouge national par pays.

        Les noms des filiales nationales soumis pour protection dans le DNS comprennent les noms officiels des 190 filiales nationales agréées au sein du mouvement et, si elles ont des noms distincts, leurs noms usuels.

        (3) les organisations respectives de la Croix-Rouge et du Croissant-Rouge doivent préserver la capacité d’enregistrer leurs noms si elles le souhaitaient, et s’il n’existe pas d’autres utilisations légitimes de ces noms.

        Attendu que, les participants à la discussion facilitée ont fait remarquer que, suite à l’achèvement du PDP de la GNSO, le GAC a fourni des orientations supplémentaires concernant les identificateurs spécifiques du mouvement de la Croix-Rouge Internationale et du Croissant-Rouge pour lesquels il demandait des protections (https://gacweb.icann.org/download/attachments/28278854/Final%20Communique%20-%20Singapore%202014.pdf?version=1&modificationDate=1397225538000&api=v2 [PDF, 145 KB]).

        Attendu que, le GAC a remis des avis au Conseil de l’ICANN dans le Communiqué de Copenhague [PDF, 190 KB] pour « demander à la GNSO de réexaminer sans tarder ses recommandations de 2013 concernant la protection des noms et des identificateurs de la Croix-Rouge et du Croissant-Rouge (définis comme les noms de « Niveau 2 » dans le processus de la GNSO) qui seraient incompatibles avec l’avis du GAC ».

        Attendu que, le Conseil a examiné les résultats de la discussion facilitée et l’avis du GAC dans le cadre de la mission de l’ICANN et de l’engagement de l’ICANN de respecter sa mission conformément aux principes pertinents du droit international, des conventions internationales et de la législation locale, tel qu’exprimé dans les statuts constitutifs de l’ICANN.

        Il est résolu (2017.03.16.13) que le Conseil d’administration demande que la GNSO lance son processus d’amendements ou modifications aux politiques approuvées, tel que décrit dans la Section 16 du manuel de PDP de la GNSO, pour envisager d’amender la section 3.1 de la recommandation 5 du rapport final du groupe de travail consacré au PDP, comme suit :

        (1) les noms complets des 190 filiales nationales de la Croix-Rouge et les noms complets du Comité International de la Croix-Rouge et la Fédération Internationale de filiales de la Croix-Rouge et du Croissant-Rouge doivent être inclus dans la spécification 5 du contrat de registre gTLD de base, où une procédure d’exception serait créée pour les cas où l’organisation du mouvement de la Croix-Rouge et du Croissant-Rouge souhaiterait demander leur chaîne protégée au second niveau ;

        (2) en plaçant les identificateurs spécifiés dans la spécification 5 du contrat de registre gTLD de base, cela devrait s’appliquer à une correspondance exacte du nom complet de la filiale nationale pertinente reconnue par le mouvement international de la Croix-Rouge et du Croissant-Rouge (en anglais comme dans les langues officielles de son état d’origine), les noms complets du Comité international de la Croix-Rouge et la Fédération internationale de filiales de la Croix-Rouge et du Croissant-Rouge (dans les six langues officielles des Nations Unies) et un ensemble défini restreint de variations de ces noms ; et

        (3) pour l’examen de la demande du Conseil d’administration, le Conseil est invité à prendre dûment en considération ces facteurs et les avis de politique publique afin de réserver la liste limitée de noms des filiales nationales de la Croix-Rouge et du Croissant-Rouge, tels que reconnus au sein du mouvement international de la Croix-Rouge et du Croissant-Rouge, dans tous les gTLD.

        Il est résolu (2017.03.16.14) que le Conseil d’administration remercie M. Bruce Tonkin pour avoir facilité les discussions conjointes GAC-GNSO sur ce sujet et remercie les représentants du GAC et de la GNSO ayant participé aux discussions facilitées pour leur participation de bonne foi et leur volonté de travailler à une réconciliation sur la question.

        Fondements des résolutions 2017.03.16.13 et 2017.03.16.14

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

        Le Conseil prend des mesures en ce moment pour faire avancer les discussions de la communauté au sujet de la protection de second niveau dans tous les gTLD pour les identificateurs du mouvement international de la Croix-Rouge et du Croissant-Rouge. La résolution du Conseil d’administration est liée aux mesures précédentes du Conseil pour adresser les avis du GAC et les recommandations de politique consensuelles de la GNSO sur la question plus large des protections dans les gTLD pour les identificateurs (noms et acronymes) des organisations internationales gouvernementales (OIG) et des organisations internationales non-gouvernementales (OING).

        En novembre 2013 la GNSO a complété un processus d’élaboration de politiques (PDP) qui a abouti à des recommandations de politiques consensuelles pour protéger les identificateurs des OIG et des OING aux premier et second niveaux dans tous les gTLD.

         Le 30 avril 2014 le Conseil d’administration a approuvé certaines, mais pas la totalité, des recommandations de politiques consensuelles du conseil de la GNSO issues du rapport final sur la protection des identificateurs des OIG et des OING dans tous les gTLD génériques du groupe de travail consacré au PDP [PDF, 644 KB]. À ce moment-là, le Conseil a demandé un délai supplémentaire pour examiner les autres recommandations de politiques consensuelles, parce que le Conseil d’administration avait reçu des avis contradictoires du GAC sur le même sujet. Le Conseil a décidé de faciliter les discussions entre les parties concernées afin de réconcilier les différences entre les recommandations de politiques de la GNSO et les avis du GAC sur le sujet.

        Entre juin 2014 et janvier 2015, le Conseil d’administration et le conseil de la GNSO ont tenu des discussions sur l’incompatibilité entre l’avis du GAC et la politique approuvée par la GNSO, ce qui a évoqué la possibilité que la GNSO considère une modification de sa recommandation de PDP sur les identificateurs de niveau 2 du mouvement international de la Croix-Rouge et du Croissant-Rouge (voir, par exemple, la lettre du président du Comité du programme des nouveaux gTLD (NGPC) du Conseil d’administration au président de la GNSO du 16 juin 2014 : https://gnso.icann.org/en/correspondence/chalaby-to-robinson-24jul14-en.pdf [PDF, 276 KB]). Plus récemment, à ICANN57, le Conseil a proposé que le GAC et la GNSO s’engagent dans une discussion facilitée, de bonne foi pour tenter de résoudre les incohérences entre l’avis du GAC et les recommandations de politiques consensuelles de la GNSO. Cela comprenait certaines désignations du mouvement international de la Croix-Rouge et du Croissant-Rouge (dénommés « identificateurs de niveau 2 » par le groupe de travail consacré au PDP).

        Quelle est la proposition à l’étude ?

        À l’ICANN58, des représentants du GAC et de la GNSO ont tenu une discussion facilitée concernant les protections pour les identificateurs du mouvement international de la Croix-Rouge et du Croissant-Rouge (recommandations 5 et 6 de la Section 3.1. du rapport final du groupe de travail consacré au PDP). Cette discussion était fondée sur les documents examinés par les parties concernées. Ces identificateurs spécifiques examinés étaient les 190 noms3 des filiales nationales de la Croix-Rouge et du Croissant-Rouge (p. ex. la Gambia Red Cross Society) (dénommés « identificateurs de niveau 2 » par le groupe de travail consacré au PDP).

        Les recommandations de politiques consensuelles de la GNSO comprises dans rapport final du 10 novembre 2013 conseillent que les identificateurs de niveau 2 soient placés dans le Centre d’échange d’information sur les marques pour protection à travers un processus de notification des réclamations de 90 jours. Les représentants du mouvement ayant participé au groupe de travail consacré au PDP ont présenté une déclaration de l’opinion minoritaire au rapport final du groupe de travail consacré au PDP notant que les protections proposées pour les identificateurs de niveau 2 ne reflètent pas les protections juridiques accordées aux désignations et aux emblèmes du mouvement par le droit international et les lois locales en vigueur dans plusieurs juridictions.

        À la fin du travail du PDP de la GNSO, le GAC a fourni des indications supplémentaires au Conseil d’administration dans son Communiqué de Singapour [PDF, 145 KB] de mars 2014 concernant la protection du mouvement international de la Croix-Rouge et du Croissant-Rouge. Le GAC a évoqué son avis précédent concernant la protection permanente contre l’utilisation non-autorisée des termes associés au mouvement international de la Croix-Rouge et du Croissant-Rouge, et a précisé que les protections devraient également inclure les 189 (aujourd’hui 190) filiales nationales de la Croix-Rouge et du Croissant-Rouge, en anglais et dans les langues officielles de leurs États d’origine respectifs, ainsi que les noms complets du Comité international de la Croix-Rouge et de la Fédération internationale des filiales de la Croix-Rouge et du Croissant-Rouge dans les six (6) langues des Nations Unies.

        Pendant les discussions facilitées, les parties concernées ont examiné les questions suivantes :

        (1) le fondement du GAC pour demander des mesures de protection permanentes pour les identificateurs du mouvement international de la Croix-Rouge et du Croissant-Rouge et ses composantes respectives (y compris les 190 filiales nationales de la Croix-Rouge et du Croissant-Rouge et les deux organisations internationales du mouvement – le Comité International de la Croix-Rouge et la Fédération internationale de la Croix-Rouge et du Croissant-Rouge) repose sur la protection des désignations « Croix-Rouge » , « Croissant-Rouge », « Lion et soleil rouges » et « Cristal-Rouge » en vertu des lois en vigueur dans les juridictions nationales multiples ; et sur les considérations de politiques publiques mondiales en matière de protection des identificateurs des organismes respectifs de la Croix-Rouge et du Croissant-Rouge de formes d’abus dans le système des noms de domaine, notamment la fraude et le détournement de fonds en cas de crise humanitaire.

        (2) la liste des noms des filiales nationales de la Croix-Rouge et du Croissant-Rouge présentée pour protection est limitée et comprend les noms des 190 filiales nationales reconnues au sein du mouvement international de la Croix-Rouge et du Croissant-Rouge – le Mouvement – en anglais et dans la ou les langue(s) et script(s) national(aux) officiel(s) de chaque filiale nationale.

        Le nombre de filiales nationales (voir la liste officielle des filiales nationales à http://www.ifrc.org/Docs/ExcelExport/NS_Directory.pdf [PDF, 657 KB]) est limité et ne peut augmenter que suite à la reconnaissance future au sein du mouvement de nouvelles filiales nationales (un événement qui doit encore faire l’objet d’un processus rigoureux et de conditions strictes définies dans les statuts du mouvement). Selon le principe fondamental de l’unité, il ne peut exister qu’une Croix-Rouge, un Croissant-Rouge ou un Cristal-Rouge national par pays.

        Les noms des filiales nationales soumis pour protection dans le DNS comprennent les noms officiels des 190 filiales nationales agréées au sein du mouvement et, si elles ont des noms distincts, leurs noms usuels.

        (3) les organisations respectives de la Croix-Rouge et du Croissant-Rouge doivent préserver la capacité d’enregistrer leurs noms si elles le souhaitaient, et s’il n’existe pas d’autres utilisations légitimes de ces noms.

        Les participants à la discussion facilitée ont fait remarquer que, suite à l’achèvement du PDP de la GNSO, le GAC a fourni des orientations supplémentaires concernant les identificateurs spécifiques du mouvement international de la Croix-Rouge et du Croissant-Rouge pour lesquels il demandait des protections. Pour cette raison, le Conseil d’administration demande que le conseil de la GNSO lance son processus d’amendements ou modifications aux politiques approuvées, tel que décrit dans la section 16 du manuel de PDP de la GNSO, pour envisager d’amender la section 3.1 de la recommandation 5 du rapport final du groupe de travail consacré au PDP, comme suit :

        (1) les noms complets des 190 filiales nationales de la Croix-Rouge et les noms complets du Comité International de la Croix-Rouge et la Fédération Internationale de filiales de la Croix-Rouge et du Croissant-Rouge doivent être inclus dans la spécification 5 du contrat de registre gTLD de base ; une procédure d’exception serait créée pour les cas où l’organisation du mouvement de la Croix-Rouge et du Croissant-Rouge souhaiterait se porter candidate pour leur chaîne protégée au second niveau ;

        (2) en plaçant les identificateurs spécifiés dans la spécification 5 du contrat de registre, cela devrait s’appliquer à une correspondance exacte du nom complet de la filiale nationale pertinente reconnue par le mouvement international de la Croix-Rouge et du Croissant-Rouge (en anglais comme dans les langues officielles de son état d’origine), les noms complets du Comité international de la Croix-Rouge et la Fédération internationale de filiales de la Croix-Rouge et du Croissant-Rouge (dans les six langues officielles des Nations Unies) et un ensemble défini restreint de variations de ces noms ; et

        (3) pour l’examen de la demande du Conseil d’administration, le conseil est invité à prendre dûment en considération ces facteurs et les avis de politique publique afin de réserver la liste limitée de noms des filiales nationales de la Croix-Rouge et du Croissant-Rouge, tels que reconnus au sein du mouvement international de la Croix-Rouge et du Croissant-Rouge, dans tous les gTLD.

        Tel que décrit dans le manuel du PDP de la GNSO, le conseil de la GNSO peut modifier ou amender des politiques consensuelles avant leur approbation finale par le Conseil d’administration de l’ICANN. Le processus pour ce faire comprend la reprise des travaux ou une nouvelle réunion de l’équipe du PDP pour examiner les amendements ou modifications proposés, la publication des révisions ou modifications proposées pour consultation publique et l’examen des amendements ou des modifications proposées par le conseil de la GNSO.

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

        La question des protections pour les identificateurs du mouvement international de la Croix-Rouge et du Croissant-Rouge a été examinée dans divers secteurs de la communauté depuis plusieurs années. Si le conseil de la GNSO accepte la demande du Conseil d’envisager l’amendement de ses recommandations de politiques consensuelles, toute modification proposée qui en résulte fera l’objet d’une période de consultation publique.

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

        La communauté a demandé que le Conseil d’administration procède à la résolution de cette question en instance dès que possible. En outre, d’autres inquiétudes communautaires sur la protection des OIG et des OING dans les recommandations de politiques de la GNSO sont résumées dans le fondement des Résolutions du Conseil 2014.04.30.03 - 2014.04.30.05, incorporées à ces présentes.

        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 :

        • le rapport final du groupe de travail consacré au PDP
        • le communiqué du GAC de Singapour (mars 2014)
        • l’énoncé du problème et les documents d’information préparés pour la discussion facilitée conjointe GAC-GNSO à l’ICANN58
        • le manuel du PDP de la GNSO

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

        Pour prendre cette mesure, le Conseil d’administration a examiné les résultats de la discussion facilitée GAC-GNSO dans le cadre de la mission de l’ICANN et de l’engagement de l’ICANN de respecter sa mission conformément aux principes pertinents du droit international, des conventions internationales et de la législation locale, tel qu’exprimé dans les statuts constitutifs de l’ICANN. Le Conseil a également examiné son rôle dans l’examen des recommandations de politiques consensuelles élaborées dans le cadre du processus ascendant d’élaboration de politiques, ainsi que son rôle dans l’examen des avis du GAC.

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

        En adoptant cette résolution, le Conseil d’administration prend une mesure pour faire progresser les travaux de la communauté sur l’élaboration d’une résolution définitive sur la portée des protections pour les identificateurs du mouvement international de la Croix-Rouge et du Croissant-Rouge. Il reste des recommandations de politiques consensuelles supplémentaires du rapport final à résoudre sur la protection des identificateurs des OIG et OING dans tous les gTLD. Le Conseil d’administration continuera de travailler sur une voie permettant d’avancer sur ces autres questions ouvertes liées à la protection des OIG et des OING.

        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 ?

        Il n’y a aucune répercussion financière à prévoir pour l’ICANN, la communauté ou le public liée à la décision du Conseil d’administration.

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

        Cette décision du Conseil d’administration n’a aucune incidence sur la sécurité, la stabilité ou la résilience du DNS.

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

      2. Remerciements à Glen de Saint Géry

        Il est résolu (2017.03.16.15) que Glen de Saint Géry a gagné la profonde gratitude du Conseil d’administration de l’ICANN pour son service dévoué à la communauté de l’ICANN. Le Conseil lui souhaite un plein succès dans ses activités futures avec la communauté de l’ICANN et au-delà.


1 Après la publication de la déclaration finale, SportAccord a contacté le panel IRP et lui a indiqué que, le 25 août 2014, le médiateur a publié un rapport final ; par la suite, il a suggéré que le panel a fait une erreur au paragraphe 7.77 de la déclaration finale. Le panel a répondu « qu’il n’apportera aucune modification à la déclaration finale » parce que : (1) « aucune demande n’a été déposée par aucune des parties conformément aux règles de l’ICDR pour corriger « une erreur d’écriture, de frappe ou de calcul dans la déclaration, » y compris au paragraphe 7.77 » ; (2) « il n’est pas évident qu’une modification apportée à la déclaration finale pour adresser les préoccupations de SportAccord au sujet du paragraphe 7.7 correspondrait à une « erreur d’écriture, de frappe ou de calcul » que le panel corrigerait à sa propre initiative » ; et (3) la discussion dans le paragraphe 7.7 de la déclaration finale reste précise dans le contexte de la discussion parce que le médiateur n’a pas élaboré de rapport final avant la décision relative à la deuxième demande de réexamen ».

2 Le 1er mars 2017, SportAccord a envoyé une lettre au Comité de gouvernance du Conseil d’administration fournissant une analyse de SportAccord sur la déclaration finale et les procédures suggérées pour aller de l’avant avec la recommandation du panel (disponible à https://www.icann.org/en/system/files/correspondence/baumann-to-disspain-01mar17-en.pdf [PDF, 467 KB]).

3 Au moment de l’élaboration de recommandations de politiques consensuelles, il existait 189 noms de filiales nationales. Une filiale nationale supplémentaire a été approuvée dans la période qui s’est écoulée depuis et quelques noms supplémentaires sont en cours d’approbation.

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