Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

Activités et réunions du Conseil d’administration

Consulter les mesures et les décisions prises par le Conseil d’administration de l’ICANN lors de ses plus récentes réunions et activités.

Résolutions approuvées par le Conseil d’administration | Réunion extraordinaire du Conseil d’administration de l’ICANN 9 août 2016

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-2016-08-09-en

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal
  2. Ordre du jour principal :
    1. Charte du Comité de révision de l’évolution de la zone racine (RZERC)
    2. Acte constitutif de la PTI
    3. Contrat de service pour la maintenance de la zone racine
    4. Acte constitutif reformulé de l’ICANN
    5. Recommandations de politiques de la GNSO relatives à l’accréditation des services d’anonymisation et d’enregistrement fiduciaire
    6. Examen de la recommandation du BGC relative à la demande de réexamen 16-3 (.GAY)
    7. Examen de la déclaration finale de l’IRP dans l’affaire Dot registry c. ICANN
    8. Examen de la demande d’annulation de la candidature du domaine de premier niveau HOTEL S.a.r.l. (HTLD) pour .HOTEL
  3. Réunion exécutive - Confidentiel :
    1. Prime de risque du médiateur pour l’exercice fiscal 2016
    2. Rémunération de l’agent

 

  1. Ordre du jour approuvé :

    1. Approbation du procès-verbal

      Il est résolu (2016.08.09.01) que le Conseil d’administration approuve les procès-verbaux des réunions du Conseil d’administration de l’ICANN du 25 et 27 juin 2016.

  2. Ordre du jour principal :

    1. Charte du Comité de révision de l’évolution de la zone racine (RZERC)

      Attendu que, l’ICANN a élaboré la proposition de charte du Comité de révision de l’évolution de la zone racine (RZERC) en coopération avec l’équipe de supervision de la mise en œuvre (IOTF) et le groupe de travail intercommunautaire sur les fonctions de nommage (CWG-Supervision).

      Attendu que, la proposition de charte est conforme à la proposition du groupe de coordination pour la transition du rôle de supervision des fonctions IANA (ICG) que le Conseil d’administration a approuvée et transmise à l’Administration nationale des télécommunications et de l’information des États-Unis (NTIA) le 10 mars 2016.

      Attendu que, l’ICANN a organisé une période de consultation publique entre le 30 juin 2016 et le 10 juillet 2016 <https://www.icann.org/public-comments/draft-rzerc-charter-2016-06-10-en> eu égard à la proposition de charte <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.pdf> [PDF, 43 KB].

      Attendu que, le forum de commentaire public portant sur la proposition de charte a pris fin le 10 juillet 2016 et l’ICANN a reçu au total sept commentaires de la part d’individus et d’organisations/groupes. Pour l’examen de ces commentaires, l’ICANN a collaboré avec les segments de la communauté de l’ICANN affectés afin de répondre aux préoccupations soulevées et de réviser la charte en conséquence.

      Attendu que, la charte du RZERC exige qu’un représentant du Conseil d’administration de l’ICANN siège au Comité.

      Il est résolu (2016.08.09.02) que le Conseil d’administration approuve la charte du RZERC telle que révisée après examen des commentaires publics, et le président-directeur général, ou son ou ses représentants, est autorisé à prendre les mesures adéquates afin de former le RZERC.

      Il est résolu (2016.08.09.03) que le Conseil d’administration nomme Suzanne Woolf pour siéger au RZERC.

      Fondements des résolutions 2016.08.09.02 – 2016.08.09.03

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

      Le 10 mars 2016, le Conseil d’administration a approuvé et transmis la proposition du groupe de coordination pour la transition du rôle de supervision des fonctions IANA (ICG) à l’Administration nationale des télécommunications et de l’information (NTIA) et a enjoint à l’ICANN de procéder à la planification de la mise en œuvre. L’une des exigences prévues dans la partie relative au nommage de la proposition de l’ICG est la formation d’un comité permanent chargé d’examiner les propositions de modifications architecturales du contenu de la zone racine du DNS, les systèmes, y compris les composants logiciels et matériels, utilisés pour la mise en œuvre des modifications de la zone racine du DNS, et les mécanismes utilisés pour la distribution de la zone racine du DNS. Le Comité devra, lorsque ses membres le jugeront nécessaire, formuler des recommandations relatives auxdites modifications à des fins d’examen par le Conseil d’administration de l’ICANN. L’approbation par le Conseil d’administration des recommandations du Comité est la proposition de remplacement du CWG-Supervision, approbation qui relevait jusqu’alors de la NTIA, mais cette dernière cessera d’exister à l’expiration du contrat des fonctions IANA. Dans le cadre de la planification de la mise en œuvre, l’ICANN a appelé ce comité permanent Comité de révision de l’évolution de la zone racine (RZERC) et a travaillé avec la communauté afin de rédiger une charte pour le Comité.

      Quelle est la proposition à l’étude ?

      La proposition de charte décrit l’objectif, l’étendue des responsabilités et la composition du Comité. La charte définit également l’organisation même du Comité, dont la fréquence et le type des réunions, la façon dont les décisions seront prises, la transcription des procès-verbaux et les conflits d’intérêts. Enfin, la charte pose les exigences en termes de révision et d’amendement de la charte.

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

      Dans le cadre de l’élaboration de la proposition de charte, l’ICANN a consulté l’équipe de supervision de la mise en œuvre (IOTF) ainsi que le CWG-Supervision. L’ICANN a également lancé une période de consultation publique sur la proposition de charte du 10 juin 2016 au 10 juillet 2016, suite à laquelle les commentaires ont été résumés et analysés.

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

      Sept (7) membres de la communauté ont participé à la période de consultation publique. Les membres de la communauté ont soulevé une préoccupation majeure dans leurs commentaires :

      les responsabilités du RZERC telles que prévues dans la proposition risquent d’empiéter sur celles du RSSAC. Les responsabilités du RZERC telles que prévues dans la proposition consistent à examiner les problèmes architecturaux et opérationnels faisant potentiellement courir un risque à la zone racine et au système racine. Les commentaires suggéraient d’interpréter ces responsabilités comme laissant la possibilité au RZERC d’examiner des questions liées au fonctionnement des serveurs racine, mission qui relève normalement du RSSAC. Afin de répondre à cette crainte, l’ICANN a travaillé avec le RSSAC pour modifier l’étendue des compétences du RZERC et indiquer ainsi clairement qu’on attend du RZERC qu’il examine les propositions de modifications architecturales du contenu de la zone racine du DNS, les systèmes, y compris les composants logiciels et matériels, utilisés pour la mise en œuvre des modifications de la zone racine du DNS, et les mécanismes utilisés pour la distribution de la zone racine du DNS. Le Comité devra, lorsque ses membres le jugeront nécessaire, formuler des recommandations relatives auxdites modifications à des fins d’examen par le Conseil d’administration de l’ICANN.

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

      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 :

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

      L’approbation par le Conseil d’administration de la charte est une étape importante du processus de planification de la mise en œuvre qui permet de satisfaire l’une des exigences de la proposition de l’ICG, qui a été entérinée par la communauté multipartite mondiale et approuvée par le Conseil d’administration le 10 mars 2016.

      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 fiscal n’est prévu.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      L’approbation de la proposition de charte constituerait une étape importante afin de garantir la sécurité, la stabilité et la résilience du DNS après la transition. Le RZERC sera tenu de fournir au Conseil d’administration de l’ICANN des recommandations relatives aux propositions de modifications architecturales du contenu de la zone racine du DNS, aux systèmes, y compris les composants logiciels et matériels, utilisés pour la mise en œuvre des modifications de la zone racine du DNS, et aux mécanismes utilisés pour la distribution de la zone racine du DNS.

    2. Acte constitutif de la PTI

      Attendu que, le 14 mars 2014, l’Agence nationale des télécommunications et de l’information (NTIA) du département du commerce des États-Unis a annoncé son intention de transférer la supervision des fonctions IANA à la communauté multipartite mondiale.

      Attendu que, le 10 mars 2016, la Société pour l’attribution des noms de domaine et des numéros sur Internet (ICANN) a accepté et transmis à la NTIA les documents de transition suivants : (i) la proposition de transition de la supervision de l’IANA du groupe de coordination de la transition du rôle de supervision des fonctions IANA (la « Proposition de l’ICG »), et (ii) le rapport de la piste de travail 1 du groupe de travail intercommunautaire chargé du renforcement de la responsabilité de l’ICANN (collectivement les « Propositions de transition »).

      Attendu que, la proposition de l’ICG prévoyait l’obligation pour l’ICANN de créer une filiale chargée d’exécuter les fonctions IANA relatives au nommage en vertu d’un contrat avec l’ICANN, la PTI. La proposition de l’ICG exigeait que la PTI soit une organisation publique californienne à but non lucratif et que l’ICANN soit le membre unique de la PTI.

      Attendu que, les avocats de l’ICANN se sont efforcés, aux côtés du conseiller indépendant du groupe de travail intercommunautaire chargé d’élaborer une proposition de transition de la supervision de l’IANA sur les fonctions de nommage (« CWG-Supervision »), de rédiger l’Acte constitutif de la nouvelle PTI. Ce projet d’Acte constitutif a été publié à des fins de consultation publique pendant 30 jours.

      Attendu que, après clôture de la période de consultation publique, une analyse détaillée des commentaires a été menée et des modifications ont été apportées à l’Acte constitutif en réponse aux commentaires publics. Pour ce travail de révision, l’ICANN a collaboré avec des cabinets juridiques indépendants.

      Attendu que, le conseiller juridique de l’ICANN a indiqué que la proposition d’Acte constitutif de la PTI était conforme aux propositions de transition et recommande que l’ICANN procède à la création de la filiale afin de poursuivre la planification de la mise en œuvre.

      Il est résolu (2016.08.09.04) que le Conseil d’administration de l’ICANN autorise le président-directeur général de l’ICANN, ou son ou ses représentants, à procéder à la création de la PTI, et notamment à déposer la proposition d’Acte constitutif de la PTI telle que révisée après examen des commentaires publics.

      Fondements de la résolution 2016.08.09.04

      L’autorisation permettant à l’ICANN de procéder à la création de la PTI via le dépôt de l’Acte constitutif de la PTI constitue une étape cruciale de la planification de la mise en œuvre des propositions de transition. Il s’agit d’une étape clé pour la communication par l’ICANN à la NTIA du statut de la planification de la mise en œuvre. Cette autorisation de poursuivre la création de la PTI est nécessaire afin de soutenir les travaux de la communauté multipartite mondiale visant à assurer la réussite de la transition de la supervision des fonctions IANA.

      Cet Acte constitutif de la PTI est le fruit d’une collaboration entre les équipes juridiques internes et externes et d’un travail intense du CWG-Supervision. L’Acte constitutif de la PTI a été publié à des fins de consultation publique pendant 30 jours et 3 commentaires ont été reçus. Chaque commentaire a été examiné et analysé et une explication a été donnée quant à la nécessité ou non de modifier l’Acte constitutif de la PTI afin de prendre en compte les questions soulevées dans le commentaire.

      Au vu du peu de commentaires reçus, il n’a pas été nécessaire d’apporter des modifications significatives à l’Acte constitutif en réponse à ces commentaires. Parmi les modifications apportées, on peut citer une modification de l’objectif de la PTI visant à refléter plus précisément le rôle limité et ciblé de la PTI eu égard aux fonctions IANA. Une autre modification a été apportée afin de tenir compte du seuil nécessaire afin d’amender l’Acte constitutif de la PTI.

      Le Conseil d’administration a fondé sa décision sur :

      Le Conseil d’administration s’est également fondé sur l’affirmation du conseiller juridique et secrétaire selon laquelle l’Acte constitutif de la PTI reflète les propositions de transition ainsi que sur les conclusions du conseiller indépendant qui préconisent de rédiger l’Acte constitutif de la PTI en soutien à la proposition de l’ICG.

      Autoriser la création de la PTI est conforme aux engagements de l’ICANN en matière de responsabilité et de transparence. Cette décision confirme la volonté de l’ICANN de mettre en œuvre les propositions de transition et l’ensemble des éléments de ces propositions.

      La création de la PTI ne devrait avoir aucun impact sur la sécurité, la stabilité ou la résilience du DNS ; la PTI sera toutefois essentielle aux travaux de l’ICANN en matière de sécurité, de stabilité et de résilience. Il y aura des répercussions sur les ressources ; des ressources non négligeables seront notamment investies afin de soutenir la création d’une nouvelle filiale.

      Il s’agit d’une fonction administrative organisationnelle pour laquelle des commentaires publics ont été reçus.

    3. Contrat de service pour la maintenance de la zone racine

      Attendu que, via une lettre envoyée à l’ICANN le 4 mars 2015, l’Administration nationale des télécommunications et de l’information des États-Unis (NTIA) a officiellement demandé à l’ICANN et à Verisign de travailler de concert en vue de trouver le meilleur moyen de transférer le rôle administratif de la NTIA dans la gestion de la zone racine, tout en veillant à préserver la sécurité, la stabilité et la résilience du système des noms de domaine de l’Internet.

      Attendu que, en août 2015, l’ICANN et Verisign ont soumis une proposition à la NTIA en réponse à sa demande <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf> [PDF, 247 KB]. La proposition contient deux parties, à savoir une période de tests menés en parallèle sur le système de gestion de la zone racine (RZMS) et un contrat de service pour la maintenance de la zone racine (RZMA) avec Verisign afin que Verisign continue d’assurer sa fonction de responsable de la maintenance de la zone racine, fonction qu’elle assure aujourd’hui en vertu de l’accord de coopération conclu avec le Département du commerce.

      Attendu que, la NTIA a indiqué dans une lettre envoyée à l’ICANN le 9 juin 2016 que la conclusion d’un RZMA et la réussite de la période de tests menés en parallèle étaient des conditions préalables à la transition de la supervision de l’IANA.

      Attendu que, la conclusion du RZMA est une exigence prévue dans la série de propositions que le Conseil d’administration a approuvées le 10 mars 2016 afin de transférer la supervision des fonctions IANA, jusqu’alors assurée par la NTIA, à la communauté multipartite mondiale et, étant donné que le montant total du RZMA est supérieur à 500 000 USD, le Conseil d’administration doit approuver la délégation du pouvoir de signature au président-directeur général.

      Attendu que, la période de tests menés en parallèle sur le RZMS s’est achevée avec succès le 6 juillet 2016 <https://www.icann.org/news/announcement-2016-07-14-en>.

      Attendu que, l’ICANN et Verisign ont terminé les négociations relatives aux conditions du projet de RZMA visant à ce que Verisign assure la fonction de responsable de la maintenance de la zone racine et publié ledit projet pendant 30 jours tel que l’exige la proposition du groupe de coordination de la transition du rôle de supervision des fonctions IANA (ICG) <https://www.icann.org/news/blog/root-zone-management-transition-update-preservation-of-security-stability-and-resiliency>.

      Attendu que, le projet de RZMA contient des dispositions incorporant des exigences du groupe de travail intercommunautaire sur les fonctions de nommage (CWG-Supervision).

      Attendu que, le Comité de finances du Conseil d’administration a examiné les implications et aspects financiers du RZMA et a constaté (i) que les coûts envisagés du contrat étaient raisonnables, (ii) que le processus d’approvisionnement avait été respecté, (iii) que les coûts étaient abordables, et a ainsi recommandé au Conseil d’administration de l’approuver.

      Il est résolu (2016.08.09.05) que le projet de RZMA est approuvé, et le président-directeur général, ou son ou ses représentants, est autorisé à prendre les décisions qu’il juge appropriées pour conclure et mettre en œuvre ledit contrat.

      Fondements de la résolution 2016.08.09.05

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

      Dans une lettre en date du 4 mars 2015, l’Administration nationale des télécommunications et de l’information des États-Unis (NTIA) « a officiellement demandé à l’ICANN et à Verisign de travailler de concert en vue de trouver le meilleur moyen de transférer le rôle administratif de la NTIA dans la gestion de la zone racine, tout en veillant à préserver la sécurité, la stabilité et la résilience du système des noms de domaine de l’Internet. » En août 2015, l’ICANN et Verisign ont soumis une proposition à la NTIA en réponse à sa demande <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf> [PDF, 247 KB]. La proposition contient deux parties, à savoir une période de tests menés en parallèle sur le système de gestion de la zone racine (RZMS) et un contrat de service pour la maintenance de la zone racine (RZMA) avec Verisign afin que Verisign continue d’assurer sa fonction de responsable de la maintenance de la zone racine, fonction qu’elle assure aujourd’hui en vertu de l’accord de coopération conclu avec le Département du commerce.

      Il est également précisé que la conclusion du RZMA est une exigence prévue dans la série de propositions que le Conseil d’administration a approuvées le 10 mars 2016 afin de transférer la supervision des fonctions IANA, jusqu’alors assurée par la NTIA, à la communauté multipartite mondiale et, étant donné que le montant total du RZMA est supérieur à 500 000 USD, le Conseil d’administration doit approuver la délégation du pouvoir de signature au président-directeur général.

      Depuis août dernier, l’ICANN et Verisign mènent des discussions et des négociations eu égard aux conditions du RZMA. Les négociations ont pris fin en juin et le projet de RZMA a été publié le 30 juin 2016 pendant 30 jours. Cette période de consultation publique a pris fin le 30 juillet 2016 et le Conseil d’administration a examiné le projet de RZMA à des fins d’approbation.

      Quelle est la proposition à l’étude ?

      Le projet de RZMA permet à Verisign de continuer à fournir des services en matière de maintenance de la zone racine, de signature de la zone racine avec la ZSK et de distribution du fichier de zone racine et fichiers connexes aux opérateurs de la zone racine en contrepartie de frais nominaux. Le RZMA, d’une durée de 8 ans, permet la conclusion de conventions de service qui peuvent être modifiées via un processus de contrôle des changements dans l’hypothèse où les clients de l’IANA exigeraient de modifier ces conventions. Le processus de contrôle des changements permet également de procéder à des modifications du système de gestion de la zone racine dans la mesure où la gestion de la zone racine doit s’adapter afin de répondre aux besoins de la communauté. Bien que la durée du RZMA, 8 ans, soit censée promouvoir la sécurité, la stabilité et la résilience des opérations de maintenance de la zone racine en maintenant le rôle de Verisign, le contrat prévoit également pour la communauté, dans le cadre d’un processus communautaire et consensuel, la possibilité d’imposer à l’ICANN le transfert de ces fonctions à un autre prestataire de services après trois ans. L’intégralité du RZMA a été publié pendant 30 jours à compter du 30 juin 2016 tel que requis par la proposition de l’ICG et peut être consulté sur <https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0>.

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

      L’ICANN a mené des discussions et des négociations avec Verisign, Inc. afin d’achever le projet de RZMA, qui a ensuite été publié pendant 30 jours entre le 30 juin et le 30 juillet 2016.

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

      Aucune question ou inquiétude n’a été portée à l’attention de l’ICANN pendant cette période de 30 jours.

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

      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é le RZMA afin de s’assurer qu’il contenait des dispositions qui permettraient à l’ICANN de satisfaire les exigences de la communauté eu égard à la transition, par exemple :

      • La possibilité de modifier les conventions de service suite à des recommandations du Comité permanent de clients
      • La possibilité d’apporter des modifications au système de gestion de la zone racine suite à des recommandations du Comité de révision de l’évolution de la zone racine
      • La possibilité pour la communauté, dans le cadre d’un processus communautaire et consensuel, d’imposer à l’ICANN le transfert de la fonction de responsable de la maintenance à un autre prestataire de services.
      • Le Conseil d’administration a aussi soigneusement examiné les conditions du RZMA afin de veiller à ce que la fonction de responsable de la maintenance soit toujours assurée de manière sécurisée, stable et fiable après la transition.

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

      Un des principaux objectifs du projet de RZMA et un engagement réitéré de la part de Verisign, Inc. pour l’exécution de la fonction de responsable de la maintenance est d’assurer un fonctionnement sécurisé et stable de la zone racine tout au long de la transition de la supervision de l’IANA et par la suite. L’approbation par le Conseil d’administration du projet de RZMA permettrait de continuer de répondre aux attentes des clients de l’IANA.

      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 ?

      Verisign, Inc. a toujours assuré seule la fonction de responsable de la maintenance à titre gratuit et il est souhaitable de faire directement appel à Verisign, Inc. pour la poursuite de l’exécution de cette mission afin de garantir la continuité, la sécurité et la stabilité au cours de la période de transition. Les conditions prévues par le RZMA permettent à la communauté, via un processus communautaire et consensuel, d’imposer à l’ICANN le transfert de la fonction de responsable de la maintenance à un autre prestataire de services. Ce contrat prévoit de verser chaque année à Verisign, Inc. des frais nominaux d’un montant de 300 000 USD pour l’exécution de la fonction de responsable de la maintenance. Le Comité de finances du Conseil d’administration de l’ICANN a examiné les implications et les aspects financiers du projet de RZMA et a recommandé, sur le fondement de cet examen, l’approbation du RZMA par le Conseil d’administration de l’ICANN.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      L’approbation par le Conseil d’administration du projet de RZMA assurerait la continuité, la sécurité et la stabilité du fonctionnement de la zone racine tout au long de la transition de la supervision et par la suite.

    4. Acte constitutif reformulé de l’ICANN

      Attendu que, le 14 mars 2014, l’Agence nationale des télécommunications et de l’information (NTIA) du Département du commerce des États-Unis a annoncé son intention de transférer la supervision des fonctions IANA à la communauté multipartite mondiale.

      Attendu que, le 10 mars 2016, la Société pour l’attribution des noms de domaine et des numéros sur Internet (ICANN) a accepté et transmis à la NTIA les documents de transition suivants : (i) la proposition de transition de la supervision de l’IANA du groupe de coordination de la transition du rôle de supervision des fonctions IANA (la « Proposition de l’ICG »), et (ii) le rapport de la piste de travail 1 du groupe de travail intercommunautaire chargé du renforcement de la responsabilité de l’ICANN (collectivement les « Propositions de transition »).

      Attendu que, l’Acte constitutif de l’ICANN doit être reformulé afin de s’aligner sur les nouveaux statuts constitutifs de l’ICANN et afin de se conformer aux propositions de transition.

      Attendu que, les avocats de l’ICANN se sont efforcés, aux côtés du conseiller indépendant du CCWG-Responsabilité, d’élaborer l’Acte constitutif reformulé de l’ICANN. Cet Acte reformulé a été publié à des fins de consultation publique pendant plus de 40 jours.

      Attendu que, après clôture de la période de consultation publique, une analyse détaillée des commentaires a été menée et des modifications ont été apportées à l’Acte constitutif en réponse aux commentaires publics. Pour ce travail de révision, l’ICANN a collaboré avec des cabinets juridiques indépendants.

      Attendu que, le conseiller juridique de l’ICANN a indiqué que la proposition d’Acte constitutif reformulé de l’ICANN était conforme aux propositions de transition et recommande au Conseil d’administration d’approuver l’amendement de l’Acte constitutif de l’ICANN et d’autoriser l’ICANN à procéder à son dépôt en temps voulu.

      Il est résolu (2016.08.09.06) que le Conseil d’administration de l’ICANN approuve la proposition d’amendement de l’Acte constitutif de l’ICANN qui sera réputé entrer en vigueur à l’expiration du contrat des fonctions IANA conclu entre l’ICANN et la NTIA.

      Il est résolu (2016.08.09.07) que le Conseil d’administration de l’ICANN autorise le président-directeur général de l’ICANN, ou son ou ses représentants, à procéder au dépôt de l’Acte constitutif reformulé une fois entré en vigueur.

      Fondements des résolutions 2016.08.09.06 – 2016.08.09.07

      L’adoption de l’Acte constitutif reformulé constitue une autre étape fondamentale de la planification de la mise en œuvre des propositions de transition. Le Conseil d’administration prend à présent cette décision afin d’apporter son soutien au rapport de situation sur la planification de la transition de l’ICANN, rapport qui doit être envoyé à la NTIA le 12 août 2016. L’adoption des amendements à l’Acte constitutif de l’ICANN vient compléter les modifications apportées aux principaux documents de gouvernance de l’ICANN qui sont nécessaires afin de s’aligner sur les propositions de transition et de soutenir les travaux de la communauté multipartite mondiale visant à assurer la réussite de la supervision des fonctions IANA.

      Cet Acte constitutif reformulé a été élaboré conjointement par les équipes juridiques et la communauté de l’ICANN. Le conseiller externe du CCWG-Responsabilité ainsi que les avocats de l’ICANN ont collaboré étroitement avec le CCWG-Responsabilité afin de s’assurer d’avoir bien compris le document et afin d’y apporter son soutien. L’Acte constitutif reformulé a été publié à des fins de consultation publique pendant plus de 40 jours, prolongation requise comprise. Six commentaires ont été reçus. Chaque commentaire a été examiné et analysé et une explication a été donnée quant à la nécessité ou non de modifier l’Acte constitutif afin de prendre en compte les questions soulevées dans le commentaire. Les équipes juridiques ont poursuivi leur étroite collaboration en matière d’élaboration des mises à jour requises de l’Acte constitutif.

      Il y a eu peu de modifications apportées à la version préliminaire de l’Acte constitutif sur le fondement des commentaires.

      Le Conseil d’administration a fondé sa décision sur :

      Le Conseil d’administration s’est également fondé sur l’affirmation du conseiller juridique et secrétaire selon laquelle l’Acte constitutif reformulé reflète les propositions de transition ainsi que sur les travaux du conseiller indépendant qui préconisent de rédiger l’Acte constitutif en soutien aux propositions de transition.

      L’adoption de cet Acte constitutif est conforme aux engagements de l’ICANN en matière de responsabilité et de transparence dans la mesure où il vient compléter les principaux documents de gouvernance dont l’ICANN doit se doter afin de fournir à la communauté des outils de responsabilité nouveaux et améliorés. Cette décision confirme la volonté de l’ICANN de procéder à des changements en matière de responsabilité.

      L’adoption de cet Acte constitutif reformulé n’est pas censée avoir d’impact sur la sécurité, la stabilité ou la résilience du DNS. Les répercussions sur les ressources pour cet Acte constitutif reformulé sont les mêmes que les éventuelles répercussions sur les ressources identifiées pour la mise en œuvre des nouveaux statuts constitutifs de l’ICANN.

      Il s’agit d’une fonction administrative organisationnelle pour laquelle des commentaires publics ont été reçus.

    5. Recommandations de politiques de la GNSO relatives à l’accréditation des services d’anonymisation et d’enregistrement fiduciaire

      Attendu que, le 31 octobre 2013, le Conseil de la GNSO a approuvé la charte d’un groupe de travail ayant pour mission la mise en place d’un processus d’élaboration de politiques, à la demande du Conseil d’administration de l’ICANN, concernant l’accréditation par l’ICANN des fournisseurs de services d’anonymisation et d’enregistrement fiduciaire de noms de domaine, comme exposé de manière plus détaillée sur http://gnso.icann.org/en/drafts/raa-pp-charter-22oct13-en.pdf [PDF, 463 KB].

      Attendu que, le PDP a suivi les étapes prévues dans les statuts constitutifs de l’ICANN, et qu’il a donné lieu à un rapport final transmis le 8 décembre 2015 au Conseil de la GNSO.

      Attendu que, le groupe de travail du PDP sur l’accréditation des services d’anonymisation et d’enregistrement fiduciaire a atteint un consensus total sur toutes ses recommandations finales (voir http://gnso.icann.org/en/issues/raa/ppsai-final-07dec15-en.pdf) [PDF, 1.24 MB].

      Attendu que, le Conseil de la GNSO a examiné et discuté des recommandations finales du groupe de travail du PDP sur l’accréditation des services d’anonymisation et d’enregistrement fiduciaire et qu’il a adopté les recommandations le 21 janvier 2016 à l’unanimité (voir http://gnso.icann.org/en/council/resolutions - 201601.)

      Attendu que, le vote du Conseil de la GNSO a dépassé le nombre de voix nécessaires (majorité qualifiée) pour imposer de nouvelles obligations aux parties contractantes de l’ICANN.

      Attendu que, conformément aux statuts constitutifs de l’ICANN, une période de consultation publique sur les recommandations approuvées s’est tenue afin que la communauté ait la possibilité de faire des commentaires sur leur adoption avant toute décision du Conseil d’administration, et les commentaires reçus ont été résumés et publiés (voir https://www.icann.org/en/system/files/files/report-comments-ppsai-recommendations-31mar16-en.pdf) [PDF, 299 KB].

      Attendu que, les statuts constitutifs de l’ICANN stipulent que le Conseil d’administration doit demander l’avis du GAC concernant « toute politique que le Conseil d’administration envisagerait d’adopter, susceptible d’avoir une incidence importante sur le fonctionnement de l’Internet ou sur une tierce partie, notamment l’application de droits ou de redevances » puis « prendre dûment en compte tout avis qui serait présenté dans les délais impartis ».

      Attendu que, le Conseil d’administration a informé le GAC de la publication des recommandations finales de la GNSO à des fins de consultation publique le 19 février 2016 (voir https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Crocker-to-Thomas-Schneider-GNSO-PDP.pdf?version=1&modificationDate=1456046942000&api=v2 [PDF, 819 KB]).

      Attendu que, dans son communiqué de Marrakech publié le 9 mars 2016, le GAC a fait savoir au Conseil d’administration de l’ICANN qu’il avait besoin de davantage de temps pour examiner les éventuelles préoccupations en matière de politique publique eu égard à l’adoption des recommandations finales du PDP (voir https://gacweb.icann.org/download/attachments/28278854/GAC Morocco 55 Communique FINAL.pdf?version=1&modificationDate=1458046221000&api=v2 [PDF, 567 KB]).

      Attendu que, le 15 mai 2016, le Conseil d’administration a accusé réception des recommandations du PDP de la GNSO et a décidé de les examiner lors de sa première réunion suivant l’ICANN 56 afin de permettre au GAC de fournir un avis, le cas échéant, en temps voulu (voir https://www.icann.org/resources/board-material/resolutions-2016-05-15-en - 2.a).

      Attendu que, dans son communiqué d’Helsinki publié le 30 juin 2016, le GAC a conseillé au Conseil d’administration de l’ICANN d’enjoindre à l’équipe de révision de la mise en œuvre, convoquée afin de mettre en œuvre les recommandations adoptées, de répondre efficacement, dans la mesure du possible, aux craintes du GAC (voir https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee?preview=/27132037/43712639/20160630_GAC%20ICANN%2056%20Communique_FINAL%20.pdf [PDF, 328 KB]).

      Il est résolu (2016.08.09.08) que le Conseil d’administration adopte par les présentes l’ensemble des recommandations finales du groupe de travail du PDP sur l’accréditation des services d’anonymisation et d’enregistrement fiduciaire, telles que votées à l’unanimité par le Conseil de la GNSO le 21 janvier 2016 (les « Recommandations de politiques relatives à l’anonymisation/l’enregistrement fiduciaire »).

      Il est résolu (2016.08.09.09) que le Conseil d’administration enjoint au président-directeur général, ou son ou ses représentants autorisés, d’élaborer et d’exécuter un plan de mise en œuvre, comprenant les coûts et les échéances, pour les recommandations de politiques relatives à l’anonymisation/l’enregistrement fiduciaire conforme à l’Annexe A des statuts constitutifs de l’ICANN et aux directives et principes de l’équipe de révision de la mise en œuvre approuvés par le Conseil d’administration le 28 septembre 2015 (voir https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f), et de poursuivre la communication auprès de la communauté eu égard à de tels travaux. Dans l’hypothèse où des problèmes politiques se poseraient lors des discussions relatives à la mise en œuvre, ils devront être renvoyés à la GNSO conformément au cadre de mise en œuvre associé aux recommandations politiques de la GNSO, y compris les directives et principes de l’équipe de révision de la mise en œuvre.

      Il est résolu (2016.08.09.10) que le Conseil d’administration prend note de l’avis du GAC consigné dans le communiqué d’Helsinki eu égard aux recommandations de politiques relatives à l’anonymisation/l’enregistrement fiduciaire. Le Conseil d’administration examinera l’avis du GAC et transmettra ses conclusions à l’équipe de révision de la mise en œuvre afin qu’elle en tienne compte dans la planification de la mise en œuvre.

      Fondements des résolutions 2016.08.09.08 – 2016.08.09.10

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

      Au début des négociations avec le groupe des représentants des bureaux d’enregistrement pour le nouveau contrat d’accréditation de bureau d’enregistrement (RAA) en octobre 2011, le Conseil d’administration de l’ICANN a également demandé un rapport thématique à la GNSO qui, à l’issue des négociations du RAA, commencera un processus d’élaboration de politiques (PDP) pour traiter des problèmes non résolus lors des négociations du RAA. En juin 2013, le Conseil d’administration de l’ICANN a approuvé le nouveau RAA 2013, et le thème de l’accréditation des services d’anonymisation et d’enregistrement fiduciaire a été considéré comme la seule question qui reste à résoudre par le biais d’un PDP de la GNSO. Cette question a été soulevée par l’équipe de révision du WHOIS dans son rapport final, publié en mai 2012, dans lequel l’équipe de révision insistait sur l’absence effective de règles claires et cohérentes concernant ces services, qui donnait lieu à des résultats imprévisibles pour les parties prenantes. L’équipe de révision a estimé que la régulation et la supervision adéquates de ces services répondraient aux besoins et aux préoccupations des parties prenantes, et a recommandé que l’ICANN examine la possibilité d’instaurer un système d’accréditation. Soit jusqu’à l’élaboration d’un programme d’accréditation soit jusqu’à la mise en œuvre par l’ICANN d’un tel programme, selon la première de ces deux éventualités, seuls certains aspects de ces services sont couverts par une spécification provisoire du RAA 2013 qui arrive à expiration le 1er janvier 2017.

      Le Conseil de la GNSO a approuvé toutes les recommandations finales du rapport final du groupe de travail du PDP en date du 8 décembre 2015 lors de sa réunion du 21 janvier 2016, ainsi qu’un rapport des recommandations adressé au Conseil d’administration en février 2016. Conformément aux statuts constitutifs de l’ICANN, une période de consultation publique a été lancée afin de connaître l’avis du public sur l’adoption des recommandations, suite à quoi les recommandations du PDP ont été transmises au Conseil d’administration à des fins d’examen. Le 15 mai 2016, le Conseil d’administration a décidé de prendre une décision sur les recommandations lors de la première réunion du Conseil d’administration après l’ICANN 56 à Helsinki (Finlande) afin de permettre au GAC de donner son avis en temps voulu eu égard aux préoccupations en matière de politique publique éventuellement soulevées par les recommandations du PDP. Dans son communiqué d’Helsinki, le GAC conseillait au Conseil d’administration de faire en sorte qu’il soit répondu efficacement aux craintes du GAC, dans la mesure du possible, lors de l’étape de mise en œuvre des recommandations du PDP.

      Quelle est la proposition à l’étude ?

      Les recommandations de politiques de la GNSO comprennent des exigences obligatoires minimales pour le fonctionnement des services d’anonymisation et d’enregistrement fiduciaire ; la maintenance de points de contact désignés pour le signalement d’abus et la publication d’une liste de fournisseurs accrédités ; des exigences portant sur le traitement des demandes de divulgation et/ou de publication des coordonnées d’un client présentées par certains tiers ; des conditions liées à la divulgation et à la publication de telles coordonnées ainsi qu’au refus de divulguer ou de publier ; et des principes régissant la révocation de l’accréditation des fournisseurs de services. La liste complète ainsi que la portée des recommandations finales sont disponibles à l’Annexe A du rapport des recommandations présenté par le Conseil de la GNSO au Conseil d’administration (voir http://gnso.icann.org/en/drafts/council-board-ppsai-recommendations-09feb16-en.pdf [PDF, 491 KB]).

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

      Conformément à ce qui est prescrit dans le manuel PDP de la GNSO, le groupe de travail s’est mis en contact avec tous les groupes de représentants et les unités constitutives de la GNSO ainsi qu’avec d’autres organisations de soutien et comités consultatifs de l’ICANN au début du PDP et leur a demandé leur avis. Le groupe de travail a également organisé des séances ouvertes avec la communauté lors des réunions publiques de l’ICANN qui se sont tenues pendant la durée du PDP. Il a également sollicité les commentaires des équipes des services aux bureaux d’enregistrement et de la conformité contractuelle de l’ICANN sur d’éventuels problèmes liés à la mise en œuvre. Des périodes de consultation publique ont été lancées pour le rapport thématique préliminaire qui avait précédé le PDP, pour le rapport initial du groupe de travail ainsi que pour l’adoption par le Conseil de la GNSO du rapport final du groupe de travail. Les recommandations finales exposées dans le rapport final reposaient entièrement sur l’examen et l’analyse effectués par le groupe de travail de tous les commentaires publics et contributions reçus en réponse à son rapport initial.

      Suite à l’avis du GAC consigné dans son communiqué de Marrakech en date du 9 mars 2016 et à la résolution du Conseil d’administration du 15 mai 2016, des discussions sur ce sujet se sont également tenues au sein du Conseil d’administration et de la communauté lors de l’ICANN 56 à Helsinki (Finlande).

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

      Le groupe de travail a reçu un nombre considérable de commentaires publics concernant la possibilité de distinguer entre les titulaires de noms de domaine servant à des fins non commerciales et les titulaires qui réalisent des transactions financières en ligne. Le rapport initial du groupe de travail posait ouvertement la question, car, à l’époque, plusieurs membres du groupe de travail étaient en faveur d’une telle distinction. Après avoir délibéré davantage suite à l’examen des commentaires publics reçus, le groupe de travail est parvenu à un consensus sur la recommandation suivante : une telle distinction ne devrait pas être faite à des fins d’accréditation de services.

      Par ailleurs, des préoccupations ont été formulées quant à la nécessité de s’assurer que des sauvegardes adéquates sont en place pour préserver la confidentialité des données des clients et de concilier de manière raisonnable le besoin légitime d’accéder aux informations (par exemple, celui des organismes d’application de la loi ou des titulaires de droits de propriété intellectuelle) et celui de protéger la confidentialité. De nombreux commentaires publics reçus en réponse au rapport initial du groupe de travail ont souligné les dangers potentiels de la divulgation non justifiée d’informations confidentielles, notamment la menace à la sécurité physique de certains groupes de titulaires de noms de domaine et de clients des services d’anonymisation et d’enregistrement fiduciaire. Les recommandations finales du groupe de travail font valoir, entre autres, un certain nombre de principes et de politiques visant à fournir des lignes directrices plus concrètes que celles qui existent actuellement pour les services d’anonymisation et d’enregistrement fiduciaire, les tiers qui demandent la divulgation d’informations de client, et les titulaires de noms de domaine, au regard de questions telles que le traitement des avis envoyés aux clients, les demandes d’informations et les transferts de noms de domaine.

      Le groupe de travail a également reçu plusieurs commentaires concernant l’absence d’un cadre détaillé pour la soumission et le traitement confidentiel des demandes de divulgation provenant des organismes d’application de la loi, y compris du groupe de travail du GAC sur la sécurité publique. Dans son rapport initial, le groupe de travail a demandé l’avis de la communauté sur la question de savoir si un tel cadre devrait être élaboré et de quelle manière, ainsi que sur des questions plus spécifiques comme celle qui vise à déterminer s’il devrait être obligatoire pour les fournisseurs accrédités de se plier à la demande expresse des organismes d’application de la loi relevant de la juridiction des fournisseurs de ne pas informer le client. Sur la base des commentaires reçus, le groupe de travail a convenu que les fournisseurs accrédités de services d’anonymisation et d’enregistrement fiduciaire devraient, si la loi applicable l’exige, donner suite aux demandes expresses des organismes d’application de la loi de ne pas informer un client. Les fournisseurs seraient libres d’adopter, de leur propre initiative, des normes plus rigoureuses ou de coopérer de toute autre manière avec les organismes d’application de la loi. Le rapport final du groupe de travail suggère également d’inclure certaines exigences minimales si un tel cadre venait à être mis en place lors de l’étape de mise en œuvre des recommandations du PDP adoptées.

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

      Le Conseil d’administration a examiné le rapport final du groupe de travail du PDP, le rapport des recommandations du Conseil de la GNSO sur le sujet qui lui a été adressé, le résumé des commentaires publics reçus en réponse à la période de consultation publique lancée à la suite de l’adoption, par le Conseil de la GNSO, des recommandations figurant dans le rapport final, et les avis du GAC qu’il a reçus sur le sujet, tels que consignés dans les communiqués de Marrakech et d’Helsinki.

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

      Les recommandations ont été élaborées selon le processus d’élaboration de politiques de la GNSO, tel que décrit à l’Annexe A des statuts constitutifs de l’ICANN, et ont reçu le soutien unanime du Conseil de la GNSO. Comme indiqué dans les statuts constitutifs de l’ICANN, le soutien à la majorité qualifiée du Conseil de la GNSO oblige le Conseil d’administration à adopter la recommandation à moins qu’il ne détermine, par un vote de plus des deux tiers de ses membres, que la politique recommandée n’est pas dans l’intérêt de la communauté de l’ICANN ou de l’ICANN.

      Les statuts constitutifs offrent également au GAC la possibilité de donner son avis sur des préoccupations en matière de politique publique qui pourraient être soulevées si une proposition de politique était adoptée par le Conseil d’administration. Le GAC avait fait valoir cette possibilité pour ce PDP et le Conseil d’administration continuera de prendre en compte les avis fournis par le GAC.

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

      La mise au point d’un programme d’accréditation intégral pour les fournisseurs de services d’anonymisation et d’enregistrement fiduciaire exigera des ressources considérables et s’étalera sur une longue période. Il est probable que la spécification provisoire du RAA 2013 doive être prolongée au-delà de sa date d’expiration actuelle (1er janvier 2017) afin de permettre la mise au point d’un tel programme.

      La mise en œuvre des recommandations de la GNSO aboutira à un ensemble de normes plus uniforme eu égard à de nombreux aspects des services d’anonymisation et d’enregistrement fiduciaire, y compris des procédures plus cohérentes pour le traitement, la gestion et la détermination des demandes de tiers par des fournisseurs accrédités, procédures prévoyant des sauvegardes raisonnables visant à protéger la vie privée des consommateurs et répondant, dans la mesure du possible, aux préoccupations en matière de politique publique mises en avant par le GAC. À l’heure actuelle, il n’existe ni schéma d’accréditation pour les services d’anonymisation et d’enregistrement fiduciaire, ni ensemble convenu de meilleures pratiques élaboré par la communauté pour la prestation de tels services. Ce PDP constitue une tentative de mise en place d’une base solide pour l’élaboration et la mise en œuvre d’un cadre d’accréditation par l’ICANN et s’inscrit dans le cadre des efforts continus de l’ICANN visant à améliorer le système WHOIS, y compris la mise en œuvre des recommandations précédemment formulées par l’équipe de révision du WHOIS.

      Toujours est-il que la mise en œuvre de toutes les recommandations du PDP nécessitera, comme nous l’avons souligné plus haut, beaucoup de temps et de ressources étant donné l’ampleur du projet et le fait que ce sera la première fois que l’ICANN mettra en œuvre un tel programme pour ce secteur de l’industrie. Bien que le RAA puisse servir de référence utile pour ce programme, le rapport final du groupe de travail a établi que ce modèle n’était pas forcément le plus adéquat pour de multiples raisons. Le fait de veiller à ce que la planification de la mise en œuvre réponde au mieux aux préoccupations en matière de politique publique identifiées par le GAC, y compris la possibilité d’élaborer un cadre de divulgation pour les organismes d’application de la loi, constituera probablement une partie substantielle des travaux de mise en œuvre.

      Le rapport final du groupe de travail attire également l’attention sur certains volets qui pourraient nécessiter un travail supplémentaire, ce qui risque d’augmenter la charge de travail de la communauté dans un avenir proche. À titre d’exemple, la question des services d’anonymisation et d’enregistrement fiduciaire dans le contexte des transferts de noms de domaine devra être abordée lors de la prochaine révision de la politique de transfert de noms de domaine entre bureaux d’enregistrement.

      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 pourrait y avoir des répercussions financières sur l’ICANN liées à la création d’un nouveau programme d’accréditation ciblant spécifiquement les fournisseurs de services d’anonymisation et d’enregistrement fiduciaire. Le plan de mise en œuvre devrait tenir compte des coûts et des échéances d’une telle mise en œuvre. Dans la mesure où la spécification provisoire actuelle du RAA applicable à ces services est censée expirer le 1er janvier 2017, il devrait également être envisagé de prolonger sa durée lors de l’adoption des recommandations du PDP.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      La mise en œuvre des recommandations du PDP n’a aucune incidence directe sur la sécurité, la stabilité ou la résilience du DNS. Bien que l’accréditation des fournisseurs de services d’anonymisation et d’enregistrement fiduciaire s’inscrive dans le cadre des efforts globaux de l’ICANN visant à améliorer le système du WHOIS, elle n’a aucune incidence sur le protocole du WHOIS (y compris le déploiement du nouveau RDAP) ou ses fonctionnalités actuelles, et ne les modifie pas non plus. Le groupe de travail a émis ses recommandations finales, étant entendu que leur mise en œuvre sera effectuée dans le contexte de toute autre modification politique ou technique du système du WHOIS qui dépasse la portée de ce PDP.

    6. Examen de la recommandation du BGC relative à la demande de réexamen 16-3 (.GAY)

      Point retiré de l’ordre du jour.

    7. Examen de la déclaration finale de l’IRP dans l’affaire Dot registry c. ICANN

      Attendu que, le 29 juillet 2016, un panel (le « Panel ») chargé du processus de révision indépendante (IRP) a publié sa déclaration finale dans le cadre de l’IRP déposé par Dot Registry, LLC (Dot Registry) contre l’ICANN (la « Déclaration finale »).

      Attendu que, la majorité du panel a déclaré que « les actions et omissions du Conseil d’administration n’étaient pas conformes à l’Acte constitutif et aux statuts constitutifs de l’ICANN » en ce que « le Conseil d’administration (agissant via le BGC) n’a pas fait preuve de la diligence raisonnable et de la prudence qui lui auraient permis de disposer d’une quantité raisonnable de faits et n’a pas respecté ses obligations en matière de transparence », et que les données portées à la connaissance du panel n’étaient pas suffisantes afin d’affirmer que le Conseil d’administration (agissant via le BGC) a fait preuve d’indépendance dans le rendu des décisions relatives au réexamen. (Voir déclaration finale, ¶¶ 151-152)

      Attendu que, la majorité du panel a en outre déclaré que « Dot Registry a obtenu gain de cause » et que l’ICANN doit verser 235 294,37 USD à Dot Registry une fois que la preuve que les frais engagés ont été intégralement payés aura été apportée ». (Id. ¶ 154)

      Attendu que, « la majorité du panel a refusé de substituer son jugement à celui du panel de CPE quant au fait de savoir si Dot Registry pouvait ou non se prévaloir de la priorité communautaire ». (Id. à ¶ 153.)

      Attendu que, la majorité du panel n’a pas adressé de recommandations au Conseil d’administration eu égard à la mesure, le cas échéant, que le Conseil d’administration devrait prendre afin de se conformer à la déclaration finale.

      Attendu que, Dot Registry a indiqué dans une lettre adressée au Conseil d’administration, entre autres choses, que son « rapport d’expert de 90 pages » était « convaincant et suffisant afin d’aider le Conseil d’administration à déterminer que les candidatures de Dot Registry auraient dû être soumises à la CPE » et a demandé à l’ICANN de « conclure un contrat avec Dot Registry pour .INC, .LLC et .LLP ». (Voir https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf [PDF, 1.5 MB]).

      Attendu que, le panel a examiné et remis en cause les normes de révision existantes auxquelles a eu recours le BGC lors de l’examen des demandes de réexamen.

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

      Il est résolu (2016.08.09.11) que le Conseil d’administration accepte les conclusions suivantes consignées dans la déclaration finale : (i) Dot Registry a obtenu gain de cause dans l’IRP Dot Registry, LLC c. ICANN ; et (ii) l’ICANN versera 235 294,37 USD à Dot Registry une fois que la preuve que les frais engagés ont été intégralement payés aura été apportée.

      Il est résolu (2016.08.09.12) que le Conseil d’administration a pris note des autres conclusions de la déclaration ainsi que des conclusions relatives aux affirmations de la majorité du panel eu égard aux normes de révision pour les demandes de réexamen susmentionnées, et étudiera les prochaines étapes à suivre concernant les demandes de réexamen de Dot Registry ou les nouveaux gTLD concernés avant de prendre toute décision.

      Il est résolu (2016.08.09.13) que, à la lumière de la récente lettre envoyée par Dot Registry et des inexactitudes factuelles qui figurent dans les rapports sous forme de blogs en ligne, le Conseil d’administration enjoint au secrétaire, ou à son ou ses représentants, de publier les documents informatifs sur ce sujet en même temps que les résolutions.

      Fondements des résolutions 2016.08.09.11 – 2016.08.09.13

      Dot Registry, LLC (Dot Registry) a engagé un processus de révision indépendante (IRP) visant à contester le refus du Comité de gouvernance du Conseil d’administration (BGC) d’examiner les demandes de réexamen de Dot Registry eu égard aux rapports du panel d’évaluation de la priorité communautaire (CPE) en vertu desquels les candidatures de Dot Registry pour .INC, .LLC et .LLP, respectivement, n’ont pas été retenues lors de la CPE.

      Dot Registry a fait une demande d’exploitation des nouveaux domaines de premier niveau .LLC, .INC et .LLP. Dot Registry est l’un des neuf candidats pour .LLC, l’un des onze candidats pour .INC et l’un des quatre candidats pour .LLP. Toutefois, Dot Registry n’est pas le seul candidat ayant soumis des candidatures communautaires pour ces gTLD.

      Les panels de CPE chargés d’évaluer les candidatures de Dot Registry (les panels de CPE) ont déterminé que les candidatures ne respectaient pas les critères requis afin d’être retenus lors de la CPE ; ils ne remplissaient que cinq des 14 points requis (les « Rapports de CPE »). Dot Registry a déposé les demandes de réexamen 14-30, 14-32 et 14-33 afin que soient réexaminés les rapports de CPE. Le 24 juillet 2014, le Comité de gouvernance du Conseil d’administration (BGC) a rejeté les demandes de réexamen car il estimait que Dot Registry « n’avait pu prouver que les panels avaient agi en violation de la politique ou de la procédure établie en rendant leurs rapports de CPE respectifs »….

      Dot Registry a engagé cet IRP le 22 septembre 2014 en contestant le rejet par le BGC des demandes de réexamen de Dot Registry .LLC, .INC et .LLP., la nomination par l’ICANN de l’Economist Intelligence Unit (EIU) en tant que fournisseur tiers chargé de procéder aux CPE et la réponse du Conseil d’administration à l’avis du Comité de gouvernance du Conseil d’administration de l’ICANN concernant .LLC, .INC et .LLP.

      Dans une décision 2-1, la majorité du panel a déclaré que Dot Registry avait obtenu gain de cause et que « les actions et omissions du Conseil d’administration n’étaient pas conformes à l’Acte constitutif et aux statuts constitutifs de l’ICANN ». (Voir la déclaration finale à ¶ 151.) Plus particulièrement, la majorité du panel a déclaré que « le Conseil d’administration (agissant via le BGC) n’a pas fait preuve de la diligence raisonnable et de la prudence qui lui auraient permis de disposer d’une quantité raisonnable de faits et n’a pas respecté ses obligations en matière de transparence », et que les données portées à la connaissance du panel n’étaient pas suffisantes afin « d’affirmer que le Conseil d’administration (agissant via le BGC) a fait preuve d’indépendance dans le rendu des décisions relatives au réexamen ». (Id. බ 151-152) La majorité du panel a en outre déclaré que l’ICANN « doit verser 235 294,37 USD à Dot Registry au titre des frais, dépenses et honoraires précédemment engagés par Dot Registry, LLC une fois que la preuve que ces frais engagés ont été intégralement payés aura été apportée ». (Id. à ¶ 154)

      Le Conseil d’administration a pris note que la majorité du panel a déclaré que « le panel, afin de dégager ses conclusions, n’a pas évalué si le personnel de l’ICANN ou l’EIU n’avait lui-même pas respecté les obligations prévues par l’Acte constitutif, les statuts constitutifs ou le guide de candidature ». (Id. à ¶ 152) En outre, il est également noté que « la majorité du panel a refusé de substituer son jugement à celui du panel de CPE quant au fait de savoir si Dot Registry pouvait ou non se prévaloir de la priorité communautaire ». (Id. à ¶ 153)

      La majorité du panel a examiné et remis en cause les normes de révision existantes auxquelles a eu recours le BGC lors de l’examen des demandes de réexamen au motif qu’il estimait que lors de « l’évaluation d’une demande de réexamen », le BGC devait poser la question suivante : « La décision prise est-elle conforme à l’Acte constitutif, aux statuts constitutifs et au guide de candidature ? » (Id. ¶ 79) La majorité du panel a aussi indiqué que lors de l’examen de demandes de réexamen, « le BGC doit déterminer si le panel de CPE (dans le cas présent, l’EIU) et le personnel de l’ICANN ont respecté les principes d’équité, de transparence, d’absence de conflits d’intérêts et de non-discrimination tels que définis dans l’Acte constitutif, les statuts constitutifs et le guide de candidature de l’ICANN » (id. à ¶ 88), et que les tiers tels que l’EUI sont « tenus de respecter l’Acte constitutif et les statuts constitutifs de l’ICANN ». (Id. à ¶ 101)

      Le Conseil d’administration reconnaît l’importance des déclarations du panel eu égard aux normes de révisions utilisées pour les demandes de réexamen et étudiera les prochaines étapes à suivre concernant les demandes de réexamen de Dot Registry ou les nouveaux gTLD concernés avant de prendre toute décision.

      Comme demandé, le Conseil d’administration a pris en considération la déclaration finale. Comme l’a indiqué précédemment le Conseil d’administration, ce dernier prend très au sérieux les résultats de l’un des mécanismes de responsabilité historiques de l’ICANN.

      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.

      Le Conseil d’administration reconnaît également avoir reçu une lettre de Dot Registry, en date du 6 août 2016, indiquant, entre autres choses, que son « rapport d’expert de 90 pages » est « convaincant et suffisant afin d’aider le Conseil d’administration à décider que les candidatures de Dot Registry auraient dû être soumises à la CPE » et demandant à l’ICANN de « conclure un contrat avec Dot Registry pour .INC, .LLC et .LLP ». (Voir l’Annexe B des documents de référence et https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf [PDF, 1.5 MB].) Le Conseil d’administration souhaiterait rappeler que « la majorité du panel a refusé de substituer son jugement à celui du panel de CPE quant au fait de savoir si Dot Registry pouvait ou non se prévaloir de la priorité communautaire ». (Id. à ¶ 153.)

      En outre, le Conseil d’administration note qu’il existe bien d’autres candidatures en cours pour ces gTLD (neuf pour .INC, huit pour .LLC et trois pour .LLP) qui doivent également être examinées. Ainsi, tel que vu précédemment, le Conseil d’administration étudiera les prochaines étapes à suivre avant de prendre toute autre décision eu égard aux demandes de réexamen de Dot Registry ou aux candidatures .INC, .LLC ou .LLP.

      Enfin, le Conseil d’administration constate aussi qu’il y a eu des rapports sous forme de blogs en ligne relatant la véritable signification de la déclaration finale, et que bon nombre des éléments y figurant constituent des inexactitudes factuelles qui ont été identifiées et corrigées à l’Annexe C des documents de référence liés à ce point de l’ordre du jour.

      Cette décision n’est pas censée avoir d’impact financier direct sur l’organisation bien qu’il pourrait y avoir des coûts indirects notamment liés à l’analyse des normes utilisées pour les demandes de réexamen. Cette décision n’aura aucune incidence 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.

    8. Examen de la demande d’annulation de la candidature du domaine de premier niveau HOTEL S.a.r.l. (HTLD) pour .HOTEL

      Attendu que, Travel Reservations SRL (anciennement Despegar Online SRL), Famous Four Media Limited, Fegistry LLC, Minds + Machines Group Limited, Donuts Inc. et Radix FZC (collectivement les entités ayant posé la revendication pour .HOTEL) ont demandé que l’ICANN annule la candidature du domaine de premier niveau HOTEL S.a.r.l. (HTLD) pour .HOTEL.

      Attendu que, la demande des entités ayant posé la revendication pour .HOTEL se fonde sur les prétendus liens commerciaux de Dirk Krischenowski avec HTLD ainsi que sur son exploitation du portail qui a permis aux parties d’accéder aux informations confidentielles de différents candidats aux nouveaux gTLD, y compris des informations relatives à plusieurs entités ayant posé la revendication pour .HOTEL.

      Attendu que, selon l’enquête scientifique de l’ICANN sur le portail, l’accès non autorisé de M. Krischenowski aux informations confidentielles s’est produit seulement après que HLTD a soumis sa candidature en 2012 et après que HLTD a choisi de participer à la CPE du 19 février 2014.

      Attendu que, l’ICANN n’a trouvé aucun élément prouvant que : (i) les informations que M. Krischenowski pourraient avoir obtenues via le portail ont été utilisées afin de soutenir la candidature de HTLD pour .HOTEL ; ou (ii) les informations obtenues par M. Krischenowski ont permis à la candidature de HTLD d’être retenue lors de la CPE.

      Il est résolu (2016.08.09.14) que le Conseil d’administration arrive à la conclusion que l’annulation de la candidature de HTLD pour .HOTEL n’est pas justifiée.

      Il est résolu (2016.08.09.15) que le Conseil d’administration enjoint au président-directeur général, à ou son ou ses représentants, de poursuivre le traitement de la candidature de HTLD pour .HOTEL.

      Fondements des résolutions 2016.08.09.14 – 2016.08.09.15

      HTLD et les entités ayant posé la revendication pour .HOTEL ont chacune soumis une candidature pour .HOTEL et ont été placées dans un ensemble conflictuel. Étant donné que la candidature de HTLD était une candidature communautaire, elle a pu participer à l’évaluation de la priorité communautaire (CPE) le 19 février 2014. Après la CPE, la candidature de HTLD a été retenue le 11 juin 2014, écartant ainsi du processus les entités ayant posé la revendication pour .HOTEL.

      Les entités ayant posé la revendication pour .HOTEL ont fait valoir que l’exploitation par M. Krischenowski du portail qui a permis aux parties d’accéder aux informations confidentielles de plusieurs candidats aux nouveaux gTLD, y compris aux informations de plusieurs entités ayant posé la revendication pour .HOTEL, ainsi que les prétendus liens commerciaux de M. Krischenowski avec HTLD constituaient un motif suffisant d’annulation par l’ICANN de la candidature de HTLD pour .HOTEL.

      L’enquête scientifique de l’ICANN sur le portail a révélé que les identifiants utilisateur de M. Krischenowski et ses associés, M. Oliver Süme et Mme Katrin Ohlmer, étaient responsables de nombreux cas d’accès non autorisés prétendument intentionnels aux informations confidentielles d’autres candidats, qui se sont produits entre mars et octobre 2014. M. Krischenowski a reconnu avoir eu accès aux informations confidentielles d’autres utilisateurs mais a nié avoir agi indument ou illégalement. Entre autres choses, M. Krischenowski a fait valoir qu’il n’avait pas connaissance du mauvais fonctionnement du portail et qu’il avait utilisé l’outil de recherche en toute bonne foi. M. Krischenowski et ses associés ont également assuré qu’ils supprimeraient ou détruiraient toutes les informations obtenues et qu’ils n’avaient pas utilisées, qu’ils n’utiliseraient pas ou qu’ils ne transmettraient pas à un tiers les informations obtenues.

      Concernant les prétendus liens de M. Krischenowski avec HTLD lorsqu’il a accédé aux informations confidentielles, l’ICANN a été informée qu’il n’était pas directement lié à la candidature de HTLD pour .HOTEL en tant que contact autorisé ou en tant qu’actionnaire, directeur ou administrateur. M. Krischenowski était actionnaire à 50 % et directeur général du domaine de premier niveau HOTEL de GmbH, Berlin (GmbH Berlin), qui était actionnaire minoritaire (48,8 %) de HTLD.

      L’ICANN n’a trouvé aucun élément prouvant que : (i) les informations que M. Krischenowski pourraient avoir obtenues via le portail ont été utilisées afin de soutenir la candidature de HTLD pour .HOTEL ; ou (ii) les informations obtenues par M. Krischenowski ont permis à la candidature de HTLD d’être retenue lors de la CPE. HTLD a soumis sa candidature en 2012, a choisi de participer à la CPE le 19 février 2014 et sa candidature a été retenue le 11 juin 2014. Le premier cas d’accès non autorisé de M. Krischenowski aux informations confidentielles ne s’est pas produit avant début mars 2014, et les recherches de M. Krischenowski sur les entités ayant posé la revendication pour .HOTEL n’ont pas été effectuées avant le 27 mars, le 29 mars et le 11 avril 2014. Par conséquent, même dans l’hypothèse où M. Krischenowski aurait obtenu des informations confidentielles sur les entités ayant posé la revendication pour .HOTEL, cela n’aurait eu aucun impact sur le processus de CPE pour la candidature de HTLD .HOTEL. Plus précisément, la détermination du respect ou non par la candidature de HTLD des critères de la CPE était fondée sur la candidature telle que soumise en mai 2012, ou lorsque les derniers documents modifiant la candidature ont été téléchargés par HTLD le 30 août 2013, soit avant que M. Krischenowski ou ses associés n’aient eu accès aux informations confidentielles, c’est-à-dire entre mars 2014 et octobre 2014. De plus, rien ne prouve et les entités ayant posé la revendication pour .HOTEL ne font pas valoir que le panel de CPE a été en contact avec M. Krischenowski ou HTLD lors du processus de CPE qui a débuté le 19 février 2014.

      Suite à la résolution du Conseil d’administration du 10 mars 2016 enjoignant le « président-directeur général, ou son ou ses représentants, de mener dès que possible une enquête sur les faits allégués par les entités ayant posé la revendication pour .HOTEL concernant la configuration du portail ou de fournir un rapport au Conseil d’administration à des fins d’examen une fois l’enquête terminée » (voir les résolutions du ConseiL D’ADMINistration du 10 mars 2016 disponibles sur https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a), l’ICANN a indiqué à HTLD que les entités ayant posé la revendication pour .HOTEL demandaient à l’ICANN d’annuler la candidature de HTLD pour .HOTEL, a donné à HTLD la possibilité de répondre et a cherché des informations relatives aux liens entre HTLD et M. Krischenowski. En réponse, M. Philipp Grabensee, le désormais unique directeur général de HTLD, a confirmé à l’ICANN qu’au moment des faits incriminés, M. Krischenowski était actionnaire à 50 % et directeur général de GmbH Berlin qui était actionnaire minoritaire (48,8 %) de HTLD. M. Grabensee a également confirmé que M. Krischenowski était intervenu en tant que consultant pour la candidature de HTLD au moment de sa soumission (en 2012) et que M. Krischenowski représentait HTLD dans trois procédures d’objection relative à des chaînes prêtant à confusion engagées par HTLD à l’encontre des candidatures de Despegar et Booking.com soumises en 2013.

      M. Grabensee a également indiqué que, en accédant aux informations exclusives, M. Krischenowski n’avait agi ni pour le compte de HTLD ni en soutien à sa candidature pour .HOTEL. M. Grabensee a fait savoir que M. Krischenowski n’avait pas utilisé les codes d’accès de HTLD, n’avait pas informé le personnel de HTLD de « son intention », « n’avait fourni aucune des informations auxquelles il avait eu accès » à HTLD ou son personnel, et que le « personnel de HTLD n’avait pas connaissance de l’intention de M. Krischenowski, n’y avait pas consenti et ne l’avait pas approuvée ».

      Enfin, M. Grabensee a pris note des récentes modifications suivantes eu égard à la relation entre HTLD et M. Krischenowski : (i) les services de conseil aux entreprises liant HTLD et M. Krischenowski ont pris fin le 31 décembre 2015 ; (ii) M. Krischenowski a quitté ses fonctions de directeur général de GmbH Berlin le 18 mars 2016 ; (iii) la société en propriété exclusive de M. Krischenowski a transféré les actions (50 %) qu’elle détenait dans GmbH Berlin à Mme Ohlmer (via sa société en propriété exclusive) ; (iv) GmbH Berlin transférera les actions qu’elle détient dans HTLD à Afilias plc ; et (v) M. Grabensee est désormais l’unique directeur général de HTLD.

      Le Conseil d’administration a eu l’occasion d’examiner l’ensemble des supports soumis eu égard à la demande des entités ayant posé la revendication pour .HOTEL d’annulation de la candidature de HTLD pour .HOTEL. Après examen de toutes les informations pertinentes fournies et pour les motifs énoncés dans la résolution et les fondements, le Conseil d’administration a déterminé que l’annulation de la candidature de HTLD pour .HOTEL n’était pas justifiée et que par conséquent la demande des entités ayant posé la revendication pour .HOTEL était rejetée.

      Le Conseil d’administration prend ces revendications au sérieux et les membres du Conseil d’administration ont rendu cette décision en toute indépendance, décision réputée être dans l’intérêt de l’organisation et de la communauté dans son ensemble. Toutefois, le Conseil d’administration reconnaît que, sur la base des informations disponibles, M. Krischenowski pourrait avoir pris des mesures indues eu égard à la configuration du portail, et le Conseil d’administration envisage de prendre des mesures adéquates directement à l’encontre de M. Krischenowski.

      Cette décision n’a aucun impact financier sur l’ICANN et n’aura pas d’impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

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

  3. Réunion exécutive - Confidentiel :

    1. Prime de risque du médiateur pour l’exercice fiscal 2016

      Attendu que, le Comité des rémunérations a recommandé au Conseil d’administration d’approuver le paiement au médiateur de sa prime de risque pour l’exercice fiscal 2016.

      Il est résolu (2016.08.09.16) que le Conseil d’administration approuve par les présentes le paiement au médiateur de sa prime de risque pour l’exercice fiscal 2016.

      Fondements de la résolution 2016.08.09.16

      Tous les ans, le médiateur a la possibilité de toucher une partie de son salaire sur la base d’objectifs de performance spécifiques définis par le Conseil d’administration, à travers le Comité des rémunérations. Cela encourage le médiateur à atteindre des résultats dépassant les objectifs de performance prévus mais peut aussi amener à des contacts réguliers tout au long de l’année entre le médiateur et les membres du Conseil d’administration pour évaluer si le médiateur a effectivement atteint ses objectifs et si son travail sert toujours les intérêts de la communauté de l’ICANN.

      La notation des résultats du médiateur découle de l’auto-évaluation du médiateur ainsi que de l’examen du Comité des rémunérations, assorti d’une recommandation au Conseil d’administration.

      La notation des performances annuelles du médiateur aide à atteindre les objectifs de l’ICANN et à améliorer le service fourni par le médiateur à la communauté de l’ICANN. Si les résultats de la notation ont un impact fiscal, celui-ci est déjà pris en compte dans le budget annuel. Cette décision n’aura pas d’impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

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

    2. Rémunération de l’agent

      Attendu que, pour les opérations de l’ICANN, il est essentiel d’attirer et de conserver un personnel de haut niveau et que l’ICANN souhaite garantir à son personnel des salaires compétitifs.

      Attendu que, les données indépendantes du marché fournies par des consultants externes spécialisés en rémunération indiquent que la proposition d’augmentation de la rémunération actuelle du président de la Division des domaines mondiaux, du conseiller juridique et secrétaire, du CFO, du COO, du CIO et du vice-président responsable du soutien à l’élaboration de politiques et directeur général de l’ICANN-Istanbul, se situe dans la cible établie par l’ICANN, comprise entre le 50e et le 70e centile de la rémunération totale en espèces, basée sur des données du marché comparables pour les postes respectifs.

      Attendu que, les données indépendantes du marché fournies par des consultants externes spécialisés en rémunération indiquent que la rémunération actuelle du CFO est en dessous de la cible établie par l’ICANN, comprise entre le 50e et le 70e centile de la rémunération totale en espèces, basée sur des données du marché comparables pour les postes respectifs.

      Attendu que, la rémunération du président de la Division des domaines mondiaux, du conseiller juridique et secrétaire, du CFO et du vice-président responsable du soutien à l’élaboration de politiques et directeur général de l’ICANN-Istanbul n’a pas été ajustée depuis le 1er juillet 2014.

      Attendu que, les ajustements de rémunération pour le COO et le CIO permettront d’uniformiser le calendrier de révision des salaires des quatre autres directeurs.

      Attendu que, chaque membre du Conseil d’administration a confirmé ne pas être en conflit par rapport aux rémunérations globales avec tout autre directeur de l’ICANN.

      Il est résolu (2016.08.09.17) que le Conseil d’administration autorise, à compter du 1er juillet 2016, le président-directeur général à ajuster la rémunération, pour l’exercice fiscal 2017, de : (i) Akram Atallah, président de la Division des domaines mondiaux ; (ii) John Jeffrey, conseiller juridique et secrétaire général ; et (iii) David Olive, vice-président responsable du soutien à l’élaboration de politiques et directeur général de l’ICANN-Istanbul, conformément à l’étude indépendante sur des rémunérations comparables, sous réserve que leurs salaires de base annuels pour l’exercice fiscal 2017 n’augmentent pas de plus de 6 % par rapport à leurs salaires de base actuels.

      Il est résolu (2016.08.09.18) que le Conseil d’administration autorise, à compter du 1er juillet 2016, le président-directeur général à ajuster la rémunération pour l’exercice fiscal 2017 de Xavier Calvez, CFO, conformément à l’étude indépendante sur des rémunérations comparables, sous réserve que son salaire de base annuel pour l’exercice fiscal 2017 n’augmente pas de plus de 10 % par rapport à son salaire de base annuel actuel.

      Il est résolu (2016.08.09.19) que le Conseil d’administration autorise, à compter du 1er juillet 2016, le président-directeur général à ajuster la rémunération pour l’exercice fiscal 2017 de Susanna Bennett, COO, conformément à l’étude indépendante sur des rémunérations comparables, sous réserve que son salaire de base annuel pour l’exercice fiscal 2017 n’augmente pas de plus de 3 % par rapport à son salaire de base annuel actuel.

      Il est résolu (2016.08.09.20) que le Conseil d’administration autorise, à compter du 1er juillet 2016, le président-directeur général à ajuster la rémunération pour l’exercice fiscal 2017 d’Ashwin Rangan, CIO, conformément à l’étude indépendante sur des rémunérations comparables, sous réserve que son salaire de base annuel pour l’exercice fiscal 2017 n’augmente pas de plus de 5 % par rapport à son salaire de base annuel actuel.

      Fondements des résolutions 2016.08.09.16 – 2016.08.09.20

      Il est fondamental pour l’organisation d’attirer et de conserver un personnel de haut niveau en fournissant une rémunération globale compétitive. Un marché du travail amélioré donnera plus d’opportunités aux candidats de haut niveau extérieurs à l’ICANN.

      Le président-directeur général de l’ICANN a demandé à être autorisé à augmenter les salaires de base pour l’exercice fiscal 2017 : (i) du président de la Division des domaines mondiaux, du conseiller juridique et secrétaire et du vice-président responsable du soutien à l’élaboration de politiques et directeur général de l’ICANN-Istanbul de 6 % par rapport à leur salaire de base actuel ; (iii) du COO de 3 % par rapport à son salaire de base actuel ; et (iv) du CIO de 5 % par rapport à son salaire de base actuel. Le président-directeur général a également fait savoir au Conseil d’administration qu’il souhaitait également disposer de la même autorisation eu égard aux autres membres de l’équipe exécutive de l’ICANN n’occupant pas un poste de directeur (l’approbation du Conseil d’administration n’étant pas requise).

      L’ICANN se trouve dans une période critique qui implique d’assurer la continuité de certaines compétences et expertises, notamment au vu des principaux projets en cours comme le programme des nouveaux gTLD, l’affirmation d’engagements et autres révisions organisationnelles en cours, la transition de la supervision des fonctions IANA assurée jusqu’ici par le gouvernement des États-Unis, le renforcement de la conformité contractuelle et les initiatives de renforcement de la mondialisation, entre autres choses. Chacun de ces projets exige de disposer de dirigeants avertis et qualifiés pour garantir le respect des objectifs opérationnels de l’ICANN tout en veillant à réduire autant que possible les risques. Adhérer à la philosophie d’emploi de l’ICANN et garantir des salaires compétitifs aideront à atteindre ces objectifs.

      Toutefois, il convient de noter que la discussion menée au préalable avait établi que le plan consistait uniquement à demander l’autorisation d’augmenter les salaires des directeurs tous les deux ans. L’année dernière, le Conseil d’administration avait autorisé le président-directeur général à augmenter le salaire de base de deux directeurs qui n’avaient pas eu d’augmentation depuis leur entrée en fonction au sein de l’ICANN. Ces ajustements sont entrés en vigueur le 1er juillet 2015, date à laquelle prend effet l’ajustement des salaires du reste du personnel.

      Afin d’essayer d’uniformiser le calendrier des révisions et augmentations des salaires de tout le personnel, il est recommandé que les salaires de base des directeurs soient révisés à des fins d’ajustement cette année puis tous les ans. Il s’agit d’une modification du cycle de deux ans de révision et d’ajustement des salaires des directeurs.

      La continuité et la rétention du personnel clé pendant les principales phases organisationnelles favorisent tous les aspects de l’organisation. Par conséquent, les ajustements de salaire prévus par cette résolution auront probablement un impact positif sur l’organisation et ses initiatives visant à remplir sa mission, ainsi que sur la responsabilité et la transparence de l’organisation. Il y aura un certain impact financier sur l’organisation mais celui-ci n’aura pas de conséquences sur le budget global de l’exercice fiscal en cours et relèvera du budget de l’exercice fiscal 2017. Cette résolution n’aura pas d’impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

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