Skip to main content
Resources

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

Cette page est disponible en:

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal
    2. Acceptation du rapport final de mise en œuvre du groupe de travail de révision de la GNSO2
    3. Examen par le Comité consultatif At-Large du plan de mise en œuvre détaillé
    4. Plan opérationnel et budget de l’IANA pour EF20
    5. Conclusion du contrat pour le lieu de la réunion de l’ICANN d’octobre 2021
    6. Renouvellement du contrat et versement de l’initiative ERP (Oracle Cloud)
    7. Réaffirmation de la spécification temporaire relative aux données d’enregistrement des gTLD
  2. Ordre du jour principal :
    1. Délégation du domaine de premier niveau géographique l’موريتانيا. représentant la Mauritanie dans le script arabe à l’Université de Nouakchott Al Aasriya
    2. Délégation du domaine de premier niveau géographique .SS (Sud Soudan) à l’autorité nationale en matière de communication (NCA)
    3. Avis du GAC : Communiqué de Barcelone (octobre 2018)
    4. Adoption de la politique de consensus de la GNSO concernant certains noms de la Croix-Rouge et du Croissant-Rouge au deuxième niveau du système des noms de domaine
    5. Appartenance au comité du conseil d’administration et changements de leadership
    6. Considération de la demande de réexamen 16-11 : Travel Reservations SRL, Famous Four Media Limited (et son candidat affilié dot Hotel Limited), Fegistry LLC, Minds + Machines Group Limited, Spring McCook, LLC, and Radix FZC (et son candidat affilié dot Hotel Inc.) (.HOTEL)
    7. Considération de la demande de réexamen 18-9 : DotKids Foundation (.KIDS)
    8. Considération de la demande de réexamen 16-12 : Merck KGaA (.MERCK)
    9. Divers

 

  1. Ordre du jour approuvé :

    1. Approbation du procès-verbal

      Il est résolu (2019.01.23.01) que le Conseil d’administration approuve les procès-verbaux des réunions organisationnelle et ordinaire du 25 octobre et de la réunion extraordinaire du 6 novembre du Conseil d’administration de l’ICANN.

    2. Acceptation du rapport final de mise en œuvre du groupe de travail de révision de la GNSO2

      Attendu que, dans le cadre de la deuxième révision de l’organisation de soutien aux extensions génériques (GNSO), le 3 février 2017, le Conseil d’administration a accepté le plan de mise en œuvre de la révision de la GNSO et demandé au Conseil de la GNSO de fournir au Conseil d’administration des rapports réguliers sur les efforts de mise en œuvre.

      Attendu que, le Groupe de travail de révision de la GNSO, avec l’approbation et la surveillance du Conseil de la GNSO, a fourni au Conseil par l’intermédiaire du Comité du Conseil d’administration chargé de l’efficacité organisationnelle (OEC) des mises à jour semestrielles sur les progrès des efforts de mise en œuvre jusqu’au moment où ces derniers ont été terminés.

      Attendu que, l’OEC a surveillé les progrès des efforts de mise en œuvre grâce aux rapports de mise en œuvre semi-annuels et recommande au Conseil d’administration d’accepter le rapport final de mise en œuvre de la deuxième révision de la GNSO émis par le Groupe de travail de révision de la GNSO et approuvé par le Conseil de la GNSO le 16 août 2018.

      Il est résolu (2019.01.27.02) que le Conseil reconnaît le bon travail du Groupe de travail de révision de la GNSO et les remercie de produire le rapport de mise en œuvre des recommandations visant à améliorer l’efficacité de la GNSO, sa transparence et sa reddition de comptes, en ligne avec le calendrier proposé tel qu’énoncé dans le Plan adopté de mise en œuvre de la révision de la GNSO.

      Il est résolu (2019.01.27.03) que le Conseil d’administration accepte le rapport final de la mise en œuvre de la révision de la GNSO2 émis par le Groupe de travail de révision de la GNSO, qui marque l’achèvement de cette importante révision. Le Conseil d’administration encourage la GNSO à continuer de surveiller les répercussions de la mise en œuvre des recommandations de la deuxième révision de la GNSO dans le cadre de son processus d’amélioration continue.

      Fondements des résolutions 2019.01.27.02 – à 2019.01.27.03

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

      L’ICANN organise des révisions indépendantes de ses organisations de soutien et comités consultatifs comme prescrit par le chapitre 4 article 4.4 des Statuts de l’ICANN, pour veiller à ce que le modèle multipartite de l’ICANN demeure transparent et responsable, et pour améliorer son rendement.

      Cette résolution achève la deuxième révision de la GNSO et se base sur le rapport final de la mise en œuvre tel qu’adopté par le conseil de la GNSO, le rapport final de l’examinateur indépendant, Westlake Governance, ainsi que sur l’évaluation des recommandations par le groupe de travail de révision de la GNSO comme adoptée par le conseil de la GNSO. À la suite de l’évaluation de tous les documents pertinents et des commentaires de la communauté par l’OEC, le Conseil d’administration est maintenant en mesure d’examiner et d’accepter le rapport final de la mise en œuvre.

      Le Conseil, sur recommandation du comité du Conseil d’administration chargé de l’efficacité organisationnelle (OEC), a examiné tous les documents pertinents, y compris le rapport final, l’évaluation de la faisabilité par Groupe de travail de révision de la GNSO et la hiérarchisation des recommandations par l’examinateur indépendant (« évaluation de faisabilité »), et a accepté le rapport final publié par ce même examinateur le 25 juin 2016. Le Conseil a adopté l’évaluation de faisabilité, à l’exception des recommandations 23 et 32. En outre, le Conseil d’administration a demandé au Conseil de la GNSO de : rédiger un plan de mise en œuvre des recommandations adoptées avec un échéancier réaliste qui tienne compte de la charge de travail communautaire en permanence élevée et l’examen de l’ordre de priorité proposé par le WG ; publier ce plan au plus tard six (6) mois après l’adoption par le Conseil de l’évaluation de la faisabilité ; s’assurer que le plan de mise en œuvre inclut des définitions des résultats souhaités et un moyen de mesurer l’état actuel ainsi que les progrès vers l’atteinte des résultats souhaités ; et de faire des rapports réguliers au Conseil sur les progrès de cette mise en œuvre.

      Le 3 février 2017, le Conseil a accepté le plan de mise en œuvre fourni par le WG et approuvé par le Conseil de la GNSO le 15 décembre 2016, et demandé au WG de fournir des mises à jour deux fois par an à l’OEC jusqu’à ce que les efforts de mise en œuvre soient terminés.

      Quelle est la proposition à l’étude ?

      La proposition actuellement à l’étude est que le Conseil accepte le rapport final de mise en œuvre du WG, adopté par le Conseil de la GNSO, et examiné par l’OEC.

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

      Le Conseil, par le biais de l’OEC, a consulté le groupe de travail de révision de la GNSO, qui était responsable de la mise en œuvre, et a recommandé les bonnes pratiques pour effectuer des révisions efficaces sur une base opportune et surveillé les progrès de la révision ainsi que ceux de la mise en œuvre des recommandations découlant de la révision.

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

      Le travail de mise en œuvre mené par la GNSO a suivi ses pratiques standard pour promouvoir la transparence et la responsabilité. Aucune préoccupation n’a été exprimée par la communauté.

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

      Le Conseil a examiné les articles des statuts constitutifs pertinents, la documentation du processus de révision organisationnelle, le plan de mise en œuvre des recommandations découlant de la révision de la GNSO, et le rapport final de mise en œuvre du Groupe de travail de la révision de la GNSO.

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

      Le Conseil a trouvé plusieurs facteurs significatifs, contribuant à la réalisation effective du travail de mise en œuvre :

      • la convocation d’un groupe dédié qui supervise la mise en œuvre des recommandations acceptées par le Conseil d’administration
      • un plan de mise en œuvre comportant un calendrier réaliste pour la mise en œuvre, la définition des résultats souhaités et un moyen de mesurer l’état actuel ainsi que les progrès réalisés vers le résultat souhaité
      • des rapports détaillés et en temps opportun sur les progrès de la mise en œuvre

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

      Cette action du Conseil devrait avoir un impact positif sur la communauté en reconnaissant et en mettant en évidence une réalisation efficace de mise en œuvre des recommandations découlant de la révision de la GNSO.

      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 ?

      Cette action du Conseil est prévue ne pas avoir d’incidence budgétaire, car les efforts de mise en œuvre se sont terminés avec succès. Les conséquences sur l’organisation de l’ICANN, la communauté et le public sont prévues comme devant être positives, dans la mesure où cette décision du Conseil représente un important jalon pour des révisions organisationnelles et l’auto-gouvernance de l’ICANN.

      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’est pas censée avoir d’incidence directe sur les questions liées à la sécurité, la stabilité ou la résilience du DNS.

      Dans quelle mesure cette décision s’inscrit-elle dans la mission de l’ICANN et quel intérêt public sert-elle ?

      La décision du Conseil est compatible avec l’engagement de l’ICANN de continuer à revoir, en vertu de l’article 4.1 des statuts constitutifs les entités au sein de l’ICANN qui ont des objectifs continus, et d’améliorer la performance de ses organisations de soutien et comités consultatifs. Cette décision va servir l’intérêt public en réalisant l’engagement de l’ICANN à revoir en continu ses composants pour s’assurer que là où les gens s’engagent avec la communauté de l’ICANN, cela soutient les buts et les attentes de cette participation.

      Une consultation publique est-elle nécessaire avant que le Conseil d’administration prenne une décision ?

      Aucune consultation publique n’est nécessaire.

    3. Examen par le Comité consultatif At-Large du plan de mise en œuvre détaillé

      Attendu que, le chapitre 4 article 4.4 des statuts constitutifs de l’ICANN demande au Conseil d’administration de l’ICANN qu’il initie « une révision périodique de la performance et du fonctionnement de chaque organisation de soutien, chaque conseil d’organisation de soutien, chaque comité consultatif (à part le Comité consultatif gouvernemental), ainsi que du comité de nomination, réalisée par une ou plusieurs entités indépendantes de l’organisation étant examinée. Le but de la révision, menée conformément à des critères et des normes établis par le Conseil d’administration, consistera à déterminer (i) si cet organisme joue un rôle permanent au sein de la structure de l’ICANN, et (ii) si des changements dans sa structure ou son fonctionnement seraient souhaitables pour améliorer son efficacité ».

      Attendu que, l’examinateur indépendant de l’examen At-Large a produit un rapport final en février 2017. Ce rapport a été reçu par le Conseil en juin 2018, et dans le même temps, le Conseil a accepté l’évaluation de faisabilité des recommandations découlant de l’examen At-Large et son plan de mise en œuvre ainsi que la proposition d’aperçu de la mise en œuvre de la révision At-Large approuvée par l’ALAC.

      Attendu que, en réponse à cette résolution de juin 2018, le Groupe de travail de mise en œuvre de la révision At-Large a été créé. Ce groupe de travail a élaboré et approuvé le Plan de mise en œuvre de la révision At-Large (le « Plan de mise en œuvre ») le 19 novembre 2018, qui a été approuvé par l’ALAC le 27 novembre 2018.

      Il est résolu (2019.01.27.04) que le Conseil reconnaît le travail du groupe de travail sur la mise en œuvre de la révision At-Large et remercie les membres de ce groupe de travail pour leurs efforts.

      Il est résolu (2019.01.27.05) que le Conseil d’administration accepte le plan de mise en œuvre de la communauté At-Large y compris l’approche par étapes définie à l’intérieur. Le Conseil reconnaît que de plus amples précisions en ce qui concerne les détails de la mise en œuvre peuvent s’avérer nécessaires pour la mise en œuvre des activités des priorités 2 et 3.

      Il est résolu (2019.01.27.06) que le Conseil d’administration demande au Groupe de travail sur la mise en œuvre de la révision At-Large de fournir des mises à jour à l’OEC tous les six mois. Ces mises à jour bi-annuelles doivent identifier les réalisations mesurées à l’aune du plan de mise en œuvre existant, ainsi que des détails sur les futurs plans de mise en œuvre. C’est au cours de ces mises à jour que le Groupe de travail de la mise en œuvre de la révision At-Large fournira de plus amples détails sur les progrès en matière de mise en œuvre et les éléments mesurables. L’OEC peut demander des réunions d’information intérimaires s’il le juge nécessaire.

      Il est résolu (2019.01.03.09) que toutes les incidences budgétaires de la mise en œuvre de la révision At-Large seront considérées comme faisant partie des processus de budgétisation annuels alors applicables.

      Fondements des résolutions 2019.01.27.04 – à 2019.01.27.07

      Pour s’assurer que le modèle multipartite de l’ICANN demeure transparent et responsable, et pour améliorer ses performances, l’ICANN organise des révisions indépendantes de ses organisations de soutien et comités consultatifs comme l’exige le chapitre 4 article 4.4 des statuts constitutifs de l’ICANN. La deuxième révision At-Large a commencé en 2016 et l’examinateur indépendant a présenté son rapport final en septembre 2017.

      Les recommandations de la mise en œuvre de la révision At-Large comme notées dans la proposition d’aperçu de la mise en œuvre de la révision at-Large peuvent faire progresser les objectifs de responsabilité et de transparence de l’ICANN et ont été attentivement prises en considération par le comité du Conseil d’administration chargé de l’efficacité organisationnelle ainsi que par le Conseil d’administration dans son ensemble.

      La résolution du Conseil d’administration aura un impact positif sur l’ICANN et en particulier sur la communauté At-Large et l’ALAC étant donné qu’elle renforce l’engagement de l’ICANN et de la communauté At-Large et l’ALAC de maintenir et améliorer sa responsabilité, son efficacité organisationnelle et sa transparence tout au long du processus de mise en œuvre.

      En raison du grand nombre de recommandations qui doivent être mises en œuvre, le Conseil d’administration souscrit fortement à l’approche progressive exposée dans le plan de mise en œuvre (annexe A). Cela donnera à la communauté le temps suffisant pour affiner les détails à mesure que le processus de mise en œuvre avance – surtout durant les phases 2 et 3 de ce plan de mise en œuvre.

      Certaines recommandations – en particulier celles prévues pour être mises en œuvre au cours des phases 2 et 3 – peuvent bénéficier de détails supplémentaires concernant leur mise en œuvre exacte. En raison de la difficulté à prédire ces questions des mois à l’avance, le Conseil d’administration approuve l’idée selon laquelle le Groupe de travail de révision de la At-Large fournira des mises à jour semestrielles à l’OEC. C’est au cours de ces mises à jour que l’ALAC peut fournir de plus amples détails au sujet de la mise en œuvre, concernant les recommandations qui seront prévues pour la période de six mois à venir suivant la mise à jour respective de l’OEC. À ce moment-là, l’ALAC sera plus en mesure de signaler les variations significatives par rapport aux plan et calendrier d’origine de la mise en œuvre. Le plan de mise en œuvre de la révision de At-Large définit la hiérarchisation, l’affectation attendue des ressources en termes de travail du personnel, ainsi que des ressources Web et Wiki, les implications budgétaires attendues comme des ressources supplémentaires en personnel, et les étapes de mise en œuvre. Bien que la majorité des activités de mise en œuvre utilisera les ressources At-Large, toutes les implications financières supplémentaires sont indiquées ci-dessous. L’ALAC utilisera le processus de consultation budgétaire annuel normal pour demander les ressources nécessaires. Dans le cas où ces ressources ne lui sont pas fournies, le résultat probable serait un ralentissement sensible de la vitesse de la mise en œuvre de la révision.

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

      La présente résolution lance la phase de mise en œuvre de la deuxième révision de la communauté At-Large. Après l’évaluation du Plan de mise en œuvre et des commentaires par le Comité du Conseil d’administration chargé de l’efficacité organisationnelle, le Conseil d’administration est maintenant en mesure d’examiner le plan et d’agir face aux recommandations et de demander à l’ALAC de continuer le processus de mise en œuvre comme défini par le plan. Cette étape constitue un élément important des mécanismes de freins et contrepoids des processus de révision organisationnelle, permettant de s’assurer que l’esprit des recommandations approuvées par le Conseil d’administration sera pris en compte dans les plans de la mise en œuvre, tout en restant sensible aux contraintes budgétaires et temporelles.

      Quelle est la proposition à l’étude ?

      La proposition à laquelle le Conseil réfléchit est la recommandation du Comité en charge de l’efficacité organisationnelle de l’adoption du plan de mise en œuvre de la révision de la communauté At-Large, élaboré et adopté par le Groupe de travail de mise en œuvre de la révision d’At-Large, entériné par l’ALAC.

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

      Immédiatement après que le Conseil a adopté la résolution sur la révision de At-Large, la direction du groupe de travail de révision de la communauté At-Large a fourni des mises à jour sur le déroulement de la révision, et sur les prochaines étapes liées à chacune des cinq téléconférences mensuelles de RALO. La création du groupe de travail sur la mise en œuvre de la révision d’At-Large a impliqué un examen attentif de ses membres afin de garantir l’équilibre géographique et la diversité au sein de chaque RALO, y compris parmi les 232 structures At-Large et plus de 100 membres individuels. Lors de l’élaboration du plan de mise en œuvre de la révision de At-Large, les membres de du WG de la mise en œuvre de la révision d’At-Large ont informé régulièrement l’ALAC ainsi que chaque RALO des progrès qui étaient accomplis. Il y a eu aussi plusieurs discussions sur la mise en œuvre de la révision d’At-Large lors des séances en personnes de la réunion de l’ICANN63. À chaque étape, les commentaires ont été examinés par le WG de la mise en œuvre de la révision d’At-Large et incorporés dans le plan final.

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

      Lors de l’élaboration du Plan de mise en œuvre de la révision de At-Large, la communauté At-Large a signalé sa préoccupation sur le fait de savoir si le troisième sommet At-Large (ATLAS III) aurait lieu comme prévu provisoirement durant l’ICANN66 à Montréal en octobre 2019 et identifié comme une activité de priorité 1 nécessitant un examen sur le plan budgétaire à l’avance du cycle budgétaire global de l’organisation. En septembre 2018, le Conseil d’administration a confirmé que l’organisation de l’ICANN avait toujours autorité pour procéder à la planification et la possibilité de contracter.

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

      Le Conseil a examiné le plan de mise en œuvre de la révision d’At-Large tel qu’adopté par le Groupe de travail de mise en œuvre de la révision At-Large et entériné par l’ALAC.

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

      Les travaux pour améliorer l’efficacité de l’organisation At-Large – en mettant en œuvre les questions découlant de la révision et de la proposition de l’aperçu de la mise en œuvre de la révision d’at-Large peuvent nécessiter des ressources financières supplémentaires qui sont soumises à des processus budgétaires normaux de l’ICANN. Cette résolution n’autorise pas de financement spécifique pour ces efforts de mise en œuvre. Le Conseil comprend que certains travaux de 1re priorité, comme le développement des compétences et des efforts de communication, nécessiteront des demandes budgétaires supplémentaires durant l’EF20. Le Conseil comprend également que le processus en cours et les activités de 2de priorité sont estimés nécessiter l’ajout d’un équivalent temps plein, et il existe d’autres besoins de ressources prévus pour les éléments tels que les communications et la collecte de données.

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

      Cette action n’est pas censée avoir d’incidence directe sur la sécurité, la stabilité ou la résilience du DNS. Pourtant, une fois que les améliorations seront mises en place, les activités futures de l’ALAC et de la communauté At-Large, y compris des avis ou des apports dans les processus d’élaboration de politiques, deviendront plus transparentes et responsables, ce qui, à son tour, pourrait avoir une incidence indirecte positive sur la sécurité, la stabilité et la résilience du DNS.

      Une consultation publique est-elle nécessaire avant que le Conseil d’administration prenne une décision ?

      Le rapport préliminaire de l’auditeur indépendant a été soumis au commentaire public. Il n’est pas requis d’obtenir des commentaires publics à ce sujet avant la prise de décision du Conseil d’administration. La voix de l’ALAC a trouvé son expression tout au long du processus de révision – via le Groupe de travail de révision de la At-Large qui a effectué la proposition d’aperçu de la mise en œuvre de l’ALAC ; le Groupe de travail de la mise en œuvre de la révision d’At-Large qui a élaboré le plan de mise en œuvre ; et l’ALAC qui a adopté ce plan de mise en œuvre.

      Dans quelle mesure cette décision s’inscrit-elle dans la mission de l’ICANN et quel intérêt public sert-elle ?

      Étant donné que la communauté At-Large représente les principaux intérêts des utilisateurs individuels d’Internet dans le cadre de l’approche de gouvernance multipartite de l’ICANN, l’approbation du plan de mise en œuvre de la révision d’At-Large, qui conduira à un renforcement de la communauté At-Large, aura un impact positif direct à la mission de l’ICANN dans son processus ascendant d’élaboration des politiques. L’intérêt public est également pris en compte par le biais de cette action qui favorise la poursuite de l’élaboration et le soutien d’une communauté multipartite diversifiée et informée.

    4. Plan opérationnel et budget de l’IANA pour EF20

      Attendu que, la version préliminaire du plan opérationnel et budget (OP&B) EF209 de l’IANA a été publié le 28 septembre 2018 pour commentaire public en conformité avec les statuts de l’ICANN.

      Attendu que, les commentaires reçus par l’entremise du processus de consultation publique ont été examinés, ont fait l’objet d’une réponse et fournis aux membres du BFC pour examen et commentaires.

      Attendu que, tous les commentaires publics ont été pris en considération, et lorsque cela était approprié et faisable, ont été intégrés dans une version finale de l’OP&B EF20 de l’IANA.

      Attendu que, le Conseil des identificateurs techniques publics a adopté une version finale du PTI OP&B pour l’EF20 le 20 décembre 2018, qui est une entrée requise pour que le Conseil en tienne compte lors de l’examen de l’ensemble du OP&B de l’IANA. Par les statuts de l’ICANN, une fois OP&B de l’IANA adopté par le Conseil d’administration de l’ICANN, il est affiché sur le site Web de l’ICANN et la communauté habilitée a l’occasion d’examiner OP&B de l’IANA pour rejet.

      Attendu que, les commentaires publics reçus, de même que d’autres commentaires sollicités auprès de la communiste ont été pris en compte pour déterminer les révisions à effectuer sur la version préliminaire du plan opérationnel et budget de l’IANA de l’exercice fiscal 2020.

      Il est résolu (2019.01.27.08), que le Conseil d’administration adopte le plan opérationnel et budget EF20 de l’IANA, y compris le budget intérimaire EF20 de l’IANA.

      Fondements de la résolution 2019.01.27.08

      Conformément à l’article 22.4 des statuts constitutifs de l’ICANN, le Conseil d’administration adopte un budget annuel pour les opérations des fonctions IANA et le publie sur le site Web de l’ICANN. Le 28 septembre 2018, les versions préliminaires de l’O&B EF20 des PTI et l’OP&B EF120 de l’IANA ont été publiées pour commentaire public. Le conseil d’administration des PTI a approuvé le budget des PTI le 20 décembre 2018, et ledit budget a servi de base au budget EF20 de l’IANA.

      Les versions préliminaires publiées de l’OP&B EF20 des PTI et l’OP&B EF20 de l’IANA se sont basés sur de nombreuses discussions avec les membres de la communauté de l’ICANN et de l’ICANN org, y compris des consultations importantes avec les organisations de soutien de l’ICANN, les comités consultatifs et d’autres groupes de parties prenantes tout au long des mois précédents.

      Tous les commentaires reçus, quelle que soit leur origine ont été pris en considération lors de l’élaboration de l’OP&B EF20 de l’IANA. Là où cela était possible et approprié, ces apports ont été incorporés dans la version finale de l’OP&B EF20 de l’IANA proposée pour adoption.

      L’OP&B EF20 de l’IANA aura un impact positif sur l’ICANN, en ce sens qu’il fournit un cadre approprié pour la réalisation des services de l’IANA, et fournit également la matière permettant à l’organisation d’être tenue responsable d’une manière transparente.

      Cette décision est conforme à l’intérêt public et à la mission de l’ICANN, car elle est pleinement conforme aux plans stratégiques et opérationnels de l’ICANN, et ses résultats permettront à l’ICANN de satisfaire à sa mission.

      Un impact fiscal est à prévoir sur l’ICANN et sur la communauté à l’issue de cette décision. Des effets positifs sont à prévoir sur la sécurité, la stabilité et la résilience du système des noms de domaine (DNS) eu égard aux financements consacrés à ces aspects du DNS.

      Il s’agit d’une fonction administrative organisationnelle qui, comme indiqué ci-dessus, a déjà fait l’objet d’une consultation publique. La communauté habilitée de l’ICANN a maintenant l’occasion d’examiner si elle exercera son pouvoir de rejet sur cet OB&P.

    5. Conclusion du contrat pour le lieu de la réunion de l’ICANN d’octobre 2021

      Attendu que, l’ICANN souhaite organiser sa dernière réunion publique de 2021 dans la région de l’Amérique du Nord.

      Attendu que, l’organisation ICANN a mené un examen approfondi des lieux proposés pour tenir sa réunion dans la région nord-américaine, et est arrivée à la conclusion que le lieu le plus adapté est Seatatle, Washington.

      Résolu (2019.01.27.09), le Conseil d’administration autorise le président-directeur général, ou son/ses représentant(s), à gérer et faciliter tous les aspects liés aux contrats et aux déboursements pour le lieu d’accueil de la réunion publique de l’ICANN de mars 2021, à Marrakech au Maroc, jusqu’à concurrence de [SUPPRIMÉ POUR SERVIR LES NÉGOCIATIONS].

      Il est résolu (2019.01.27.10) que les détails de cette résolution resteront confidentiels à des fins de négociation, conformément au chapitre III, article 5.2 des statuts constitutifs de l’ICANN, jusqu’à ce que le président-directeur général en autorise la divulgation.

      Il est résolu (2019.01.27.11) que les éléments spécifiques de cette résolution restent confidentiels à des fins de négociation conformément au chapitre 3, article 3.5(b) des statuts constitutifs de l’ICANN jusqu’à ce que le Président-directeur général détermine que les informations confidentielles peuvent être divulguées.

      Fondements des résolutions 2019.01.27.09 – à 2019.01.27.11

      Dans le cadre du calendrier de réunions publiques de l’ICANN, l’ICANN organise trois fois par an une réunion dans une région géographique différente (comme définie dans les statuts de l’ICANN). L’ICANN72 se tiendra du 23 au 28 octobre 2021. À la suite d’une recherche et d’évaluation des sites disponibles, l’organisation a identifié Seattle, Washington comme un endroit approprié pour la réunion publique de l’ICANN.

      Le personnel a soigneusement examiné toutes les propositions et a préparé un document identifiant celles satisfaisant aux critères de sélection du lieu de réunion (voir http://meetings.icann.org/location-selection-criteria). Sur la base des propositions et de cette analyse, l’ICANN a décidé que la 72e réunion de l’ICANN se tiendrait à Seattle, Washington. La sélection de cet emplacement en Amérique du Nord répond aux directives de rotation géographique établies par le Groupe de travail sur la stratégie de réunion.

      Le Conseil d’administration a examiné la présentation de l’organisation ICANN visant à organiser la réunion à Seattle, Washington et la détermination que cette proposition respecte les principales conditions établies dans les critères de sélection du lieu de réunion ainsi que les coûts liés au lieu choisi pour la réunion publique de l’ICANN d’octobre 2021. L’ICANN organise des réunions publiques à l’appui de sa mission d’assurer le fonctionnement stable et sécurisé des systèmes de l’identificateur unique de l’Internet et agit dans l’intérêt public en fournissant un accès libre et ouvert à toute personne désireuse de participer, soit en personne ou à distance, dans des processus d’élaboration de politiques ascendants et multipartites ouverts, et transparent.

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

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

    6. Renouvellement du contrat et versement de l’initiative ERP (Oracle Cloud)

      Attendu que, l’ICANN a établi un besoin de renouvellement des contrats pour la solution ERP, Oracle Cloud.

      Attendu que, le comité des finances du Conseil d’administration a examiné les incidences financières de renouvellement de contrat avec Oracle Cloud pour la solution ERP de l’ICANN et a examiné des solutions de rechange.

      Attendu que, l’organisation et le comité de finances du Conseil d’administration ont recommandé au Conseil d’administration d’autoriser le PDG de l’ICANN, ou son/ses représentants, à prendre toutes les mesures nécessaires pour conclure tous les contrats nécessaires avec Oracle Cloud pour la solution ERP de l’ICANN et à procéder à toutes les dépenses requises par lesdits contrats ;

      Il est résolu (2019.01.27.12) que le Conseil d’administration autorise le PDG de l’ICANN, ou son/ses représentants, à prendre toutes les mesures nécessaires pour renouveler tous les contrats nécessaires avec Oracle Cloud pour la solution ERP de l’ICANN, et à procéder à toutes les dépenses requises par lesdits contrats.

      Il est résolu (2019.01.27.13) que les éléments spécifiques de cette résolution restent confidentiels à des fins de négociation conformément au chapitre 3, article 3.5(b) des statuts constitutifs de l’ICANN jusqu’à ce que le Président-directeur général détermine que les informations confidentielles peuvent être divulguées.

      Fondements des résolutions 2019.01.27.12 – à 2019.01.27.13

      L’ICANN a utilisé avec succès Oracle Cloud ERP depuis sa mise en œuvre en décembre 2016. Au cours des dernières années, l’Organisation de l’ICANN a progressivement augmenté sa connaissance des systèmes ERP et de traitement transactionnel et est en mesure d’apporter des améliorations incrémentielles d’efficacité afin de maximiser l’investissement original. L’ERP Oracle Cloud a remplacé des systèmes vieillissants hérités des finances, ressources humaines et approvisionnement. Cette solution fournie à l’ICANN org une solution ERP intégrée dans un système unique d’enregistrement améliorera la capacité des systèmes, les fonctions de rapport générales et les capacités d’analyse, la productivité et l’efficacité interdisciplinaire et améliorer les contrôles internes.

      Contrat actuel

      Le contrat actuel de l’ICANN avec Oracle Cloud ERP était pour une période de trois ans. Ce contrat a expiré en décembre 2018. Oracle Cloud a fourni à l’ICANN une prolongation de contrat d’un mois. Le coût annuel est [SUPPRIMÉ – AUX FINS DE NÉGOCIATION].

      Nouveau contrat

      Après une analyse approfondie, des négociations, et un ajustement du nombre de licences avec le fournisseur, l’organisation a deux options disponibles : (i) un contrat de trois ans de [SUPPRIMÉ – AUX FINS DE NÉGOCIATION] annuellement avec un coût total sur trois ans de [SUPPRIMÉ – AUX FINS DE NÉGOCIATION], (ii) un contrat de cinq ans de [SUPPRIMÉ – AUX FINS DE NÉGOCIATION] annuellement avec un coût total sur cinq ans de [SUPPRIMÉ – AUX FINS DE NÉGOCIATION].

      Après une analyse minutieuse des options présentées par l’organisation, celle d’un contrat de cinq ans est considérée comme une solution rentable et viable. Cette solution a un coût total moindre, un tarif fixe protégeant contre les augmentations pour cinq ans, et la souplesse, donnant à l’organisation la possibilité d’effectuer une autre analyse de systèmes ERP globale en trois ans (2021-2022) pour déterminer si cette solution est la meilleure pour l’ICANN.

      En outre, le Conseil a examiné les recommandations de l’organisation et du Comité de finances du Conseil d’administration au sujet de l’autorité dans le domaine de la passation de marchés et des déboursements pour le renouvellement de contrat d’Oracle Cloud pour la solution ERP.

      Cette décision du Conseil d’administration est tout à fait conforme aux missions de l’ICANN et d’intérêt public en ce qu’elle garantit que les paiements de montants importants d’une facture à une entité sont examinés et évalués par le Conseil d’administration s’ils dépassent un certain degré d’autorité déléguée via la politique de l’ICANN relative aux contrats et aux dépenses. Cela garantit que le Conseil d’administration assure un suivi des dépenses importantes et agit en tant que gardien des fonds que l’ICANN reçoit du public.

      Le renouvellement du contrat d’Oracle Cloud pour la solution ERP aura une incidence financière pour l’ICANN. Cet impact est actuellement inclus dans le plan opérationnel et budget EF20 qui attend l’approbation du Conseil d’administration. Cette action 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.

    7. Réaffirmation de la spécification temporaire relative aux données d’enregistrement des gTLD

      Attendu que, le 17 mai 2018, le Conseil d’administration a adopté la Spécification temporaire relative aux données d’enregistrement des gTLD (« Spécification temporaire ») qui prendra effet le 25 mai 2018 pour une période de 90 jours. La Spécification temporaire établit des exigences temporaires pour permettre à l’ICANN et aux opérateurs de registres et bureaux d’enregistrement de nouveaux gTLD de continuer à se conformer aux exigences contractuelles de l’ICANN et aux politiques communautaires en vigueur concernant les données d’enregistrement des gTLD (y compris le WHOIS) à la lumière du règlement général de l’Union européenne sur la protection des données (RGPD).

      Attendu que, le 21 août 2018, le Conseil d’administration a réaffirmé l'adoption de la spécification temporaire, en vigueur pour une période supplémentaire de 90 jours à partir du 23 août 2018.

      Attendu que, le 6 novembre 2018, le Conseil d’administration a réaffirmé l’adoption de la spécification temporaire, en vigueur pour une période supplémentaire de 90 jours à partir du 21 novembre 2018.

      Attendu que, le Conseil d’administration a adopté la spécification temporaire conformément aux procédures prévues dans les contrats de registre et les contrats d’accréditation des bureaux d’enregistrement pour l’adoption de politiques temporaires. Cette procédure exige que « [s]i la période pour laquelle la politique temporaire est adoptée excède quatre-vingt-dix (90) jours civils, le Conseil d’administration réitérera son adoption temporaire tous les quatre-vingt-dix (90) jours civils, pour une période totale ne pouvant dépasser un (1) an, afin de maintenir cette politique temporaire en vigueur jusqu’au moment où elle deviendra une politique de consensus ».

      Il est résolu (2019.01.27.14) que le Conseil d’administration réaffirme la Spécification temporaire relative aux données d’enregistrement des gTLD conformément aux procédures prévues dans les contrats de registre et les contrats d’accréditation des bureaux d’enregistrement pour l’établissement de politiques temporaires. En réaffirmant cette Spécification temporaire, le Conseil a déterminé ce qui suit :

      1. Les modifications qu’apporte la Spécification temporaire aux exigences existantes concernant le traitement des données à caractère personnel incluses dans les données d’enregistrement continuent d’être justifiées et l’établissement immédiat et provisoire de la Spécification temporaire reste nécessaire pour maintenir la stabilité ou la sécurité des services des bureaux d’enregistrement et opérateurs de registre, du DNS ou de l’Internet.
      2. La Spécification temporaire a été spécialement pensée pour répondre au plus près à l’objectif de maintenir la stabilité ou la sécurité des services des bureaux d’enregistrement et opérateurs de registre, du DNS ou de l’Internet.
      3. La spécification temporaire entrera en vigueur pour une période supplémentaire de 90 jours à partir du 19 février 2019.

      Il est résolu (2019.01.27.14) que le Conseil d’administration réaffirme la déclaration consultative concernant l’adoption de la spécification temporaire relative aux données d’enregistrement des gTLD, qui fixe les explications détaillées de l’adoption de la spécification temporaire et du pourquoi le Conseil d’administration estime qu’une telle spécification devrait recevoir le soutien consensuel des parties prenantes d’Internet.

      Fondements des résolutions 2019.01.27.14 – à 2019.01.27.15

      Le Règlement général de l’Union européenne sur la protection des données (RGPD) a pris effet le 25 mai 2018. Le RGPD est un ensemble de règles adoptées par le Parlement européen, le Conseil européen et la Commission européenne ; il impose de nouvelles obligations à toutes les entreprises et organisations qui collectent et conservent des « données à caractère personnel » sur les résidents de l’Union européenne (UE), au sens du droit relatif à la protection des données de l’UE. Le RGPD a des incidences sur la façon dont les données personnelles sont collectées, affichées et traitées par les participants de l’écosystème des noms de domaine gTLD (y compris les registres et les bureaux d’enregistrement) conformément aux contrats et politiques de l’ICANN.

      Le 17 mai 2018, le Conseil d’administration a adopté la Spécification temporaire relative aux données d’enregistrement des gTLD (« Spécification temporaire ») afin d’établir des exigences provisoires permettant à l’ICANN, aux opérateurs de registres et aux bureaux d’enregistrement de gTLD de continuer à se conformer aux exigences contractuelles de l’ICANN et aux politiques communautaires en vigueur concernant les données d’enregistrement des gTLD (y compris le WHOIS) à la lumière du RGPD. La Spécification temporaire, qui a pris effet le 25 mai 2018, a été adoptée en utilisant la procédure relative aux politiques temporaires établie dans les contrats de registre et dans les contrats d’accréditation de bureau d’enregistrement.

      Le 21 août 2018, le Conseil d’administration a réaffirmé la spécification temporaire pour une période supplémentaire de 90 jours à partir du 23 août 2018. Le 6 novembre 2018, le Conseil d’administration a réaffirmé l’adoption de la spécification temporaire, en vigueur pour une période supplémentaire de 90 jours à partir du 21 novembre 2018.

      Conformément à la procédure prévue dans le contrat d’accréditation de bureau d’enregistrement et le contrat de registre pour l’adoption d’une politique ou spécification temporaire, « [s]i la période pour laquelle la politique temporaire est adoptée excède quatre-vingt-dix (90) jours civils, le Conseil d’administration réitérera son adoption temporaire tous les quatre-vingt-dix (90) jours civils, pour une période totale ne pouvant dépasser un (1) an, afin de maintenir cette politique temporaire en vigueur jusqu’au moment où elle deviendra une politique de consensus ».

      Aujourd’hui, le Conseil d’administration décide de revalider la Spécification temporaire pour une période supplémentaire de 90 jours, car les exigences provisoires continuent d’être justifiées par la volonté de maintenir la stabilité ou la sécurité des services des bureaux d’enregistrement et des opérateurs de registre, ou celles du DNS. Lors de son adoption de la Spécification temporaire, le Conseil d’administration a émis une déclaration consultative expliquant en détail les motifs pour lesquels il a adopté ladite Spécification et les raisons pour lesquelles il estime que cette Spécification devrait recevoir l’appui général des parties prenantes de l’Internet. Le Conseil d’administration réaffirme l’Avis, qui est intégré, par référence, aux fondements des résolutions du Conseil.

      Tel que l’exige l’adoption d’une politique ou spécification temporaire, le Conseil d’administration a pris l’initiative pour mettre en œuvre le processus d’élaboration d’une politique de consens et a consulté le conseil du GNSO sur les voies possibles pour envisager l’élaboration d’une telle politique sur les questions découlant de la Spécification temporaire. Le processus d’élaboration de politiques de consensus doit être achevé dans un délai d’un an. Le Conseil d’administration prend acte du fait que le conseil de la GNSO a lancé un processus accéléré d’élaboration de politiques sur la Spécification temporaire et que le groupe de travail poursuit ses délibérations afin d’élaborer des recommandations de politique proposées Le 21 novembre 2018, le Groupe de travail a publié pour commentaires publics le rapport initial du Processus accéléré d’élaboration de politiques (EDPD) sur la spécification temporaire relative aux données d’enregistrement des gTLD. Le Groupe de travail a défini un calendrier pour produire un rapport final en février 2019 et qui devra être présenté au conseil d’administration pour examen avant l’expiration de la période d’un an prévu pour la spécification temporaire. Le Conseil d’administration continuera de collaborer avec le conseil de la GNSO sur la question et réitère son attachement à fournir le soutien qu’il faut au travail du processus accéléré d’élaboration de politiques afin de tenir le délai (voir la lettre du 7 août 2018 adressée par Cherine Chalaby au président du conseil de la GNSO : https://www.icann.org/en/system/files/correspondence/chalaby-to-forrest-et-al-07aug18-en.pdf).

      La décision du Conseil visant à réaffirmer la Spécification temporaire est conforme à la mission de l’ICANN qui consiste à « [...] assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet [...] ». L’un des rôles principaux de l’ICANN étant d’être responsable de l’administration des identificateurs de l’Internet aux niveaux les plus élevés, faciliter la capacité d’identifier les détenteurs de ces identificateurs est une fonction centrale de l’ICANN. La décision que prend aujourd’hui le Conseil d’administration permet de servir l’intérêt public et de répondre à l’exigence des statuts constitutifs de l’ICANN qui consiste à « évaluer l’efficacité du service actuel d’annuaire de données d’enregistrement de gTLD et à vérifier si sa mise en œuvre répond aux besoins légitimes d’application de la loi, favorise la confiance du consommateur et protège les données des titulaires de nom de domaine ». [Statuts constitutifs art. 4.6(e)(ii)]

      En outre, cette décision devrait avoir un impact immédiat sur le maintien de la sécurité, de la stabilité ou de la résilience du DNS, car elle aidera à maintenir, dans la mesure du possible, le WHOIS pendant que la communauté travaille à l’élaboration d’une politique de consensus. La réaffirmation de la Spécification temporaire n’est pas censée avoir d’impact fiscal sur l’organisation ICANN au-delà de ce qui a été précédemment défini dans les fondements des résolutions 2018.05.17.01 – à 2018.05.17.09. Si le besoin en ressource dépassait les prévisions du budget actuel pour réaliser le travail lié au WHOIS et au RGPD, le Président-directeur général présentera le besoin de toute ressource supplémentaire au Comité de finances du Conseil d’administration pour examen, conformément aux pratiques de demandes de fonds actuelles.

      Il s’agit d’une fonction administrative organisationnelle du Conseil qui ne nécessite pas de consultation publique, quoique l’approche de l’ICANN en matière de conformité aux politiques et contrats de l’ICANN concernant les données d’enregistrement des gTLD à la lumière du RGPD ait fait l’objet de commentaires de la communauté l’an passé (https://www.icann.org/dataprotectionprivacy).

  2. Ordre du jour principal :

    1. Délégation du domaine de premier niveau géographique l’موريتانيا. représentant la Mauritanie dans le script arabe à l’Université de Nouakchott Al Aasriya

      Il est résolu (2019.01.27.16) que dans le cadre de sa mission prévue par le Contrat des fonctions IANA relatives au nommage conclu avec l’ICANN, la PTI a étudié et évalué la demande de délégation du domaine de premier niveau géographique موريتانيا. à l’Université de Nouakchott Al Aasriya. La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Fondements de la résolution 2019.01.27.16

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

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

      Quelle est la proposition à l’étude ?

      Il est proposé d’approuver une demande visant à créer le domaine de premier niveau géographique موريتانيا. en alphabet arabe et à confier le rôle de gestionnaire à l’Université de Nouakchott Al Aasriya.

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

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

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

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

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

      [SUPPRIMÉ – INFORMATIONS SENSIBLES RELATIVES À UNE DÉLÉGATION]

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

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

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

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

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

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

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

      L’ICANN estime que cette demande ne représente aucun risque significatif pour la sécurité, la stabilité ou la résilience du DNS. Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    2. Délégation du domaine de premier niveau géographique .SS (Sud Soudan) à l’autorité nationale en matière de communication (NCA)

      Il est résolu (2019.01.27.17) que dans le cadre de sa mission prévue par le Contrat des fonctions IANA relatives au nommage conclu avec l’ICANN, la PTI a étudié la demande de délégation du domaine de premier niveau géographique .SS(Sud Soudan) à l’Agence nationale des télécommunications. La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Fondements de la résolution 2019.01.27.17

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

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

      Quelle est la proposition à l’étude ?

      Il est proposé d’approuver une demande visant à créer le domaine de premier niveau géographique .SS et à confier le rôle de gestionnaire à l’Agence nationale des télécommunications.

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

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

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

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

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

      [SUPPRIMÉ – INFORMATIONS SENSIBLES RELATIVES À UNE DÉLÉGATION]

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

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

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

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

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

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

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

      L’ICANN estime que cette demande ne représente aucun risque significatif pour la sécurité, la stabilité ou la résilience du DNS. Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    3. Avis du GAC : Communiqué de Barcelone (octobre 2018)

      Attendu que, le Comité consultatif gouvernemental (GAC) s’est réuni lors de l’ICANN63 à Barcelone, en Espagne, et a émis un avis auprès du Conseil d’administration de l’ICANN dans un Communiqué le 25 octobre 2018 (« Communiqué de Barcelone »).

      Attendu que, le communiqué de Barcelone a fait l’objet d’un échange entre le Conseil d’administration et le GAC le 28 novembre 2018.

      Alors que, dans une lettre du 20 décembre 2018, le GAC a fourni les précisions supplémentaires sur le langage figurant dans l’annexe du Communiqué de Barcelone intitulée Suivi de la Déclaration commune originale de l’ALAC et du GAC (Abu Dhabi, 2 novembre 2017).

      Attendu que, dans une lettre du 21 décembre 2018, adressé au Conseil d’administration, le conseil de la GNSO a fourni des commentaires concernant l’avis du communiqué de Barcelone correspondant aux domaines génériques de premier niveau pour informer le Conseil d’administration et la communauté des activités liées aux politiques des gTLD pouvant se rapporter à l’avis donné par le GAC.

      Alors que, de l’organisation de l’ICANN a publié un mémorandum et un document d’information historique qui donnent des précisions concernant le développement et l’évolution de la procédure de l’organisation de l’ICANN pour la libération des étiquettes à deux caractères au deuxième niveau et la norme-cadre des mesures pour éviter toute confusion avec les codes de pays correspondants.

      Attendu que, le Conseil d’administration a élaboré une fiche de suivi pour répondre à l’avis du GAC dans le Communiqué de Barcelone, en tenant compte du dialogue entre le Conseil d’administration et le GAC, la lettre d’éclaircissement donnée par le président du GAC, les informations fournies par le Conseil de la GNSO, et le mémorandum et document d’information publié par l’ICANN org.

      Attendu que, le Conseil a pris en considération l’avis précédemment différé du GAC concernant les codes de pays à deux caractères au deuxième niveau du Communiqué du Panama et a inclus une réponse dans la fiche de suivi actuelle de « l’avis du GAC – Communiqué de Barcelone : actions et mises à jour (25 janvier 2019) ».

      Il est résolu (2019.01.27.18) que le Conseil d’administration adopte la fiche de suivi intitulée « Avis du GAC – Communiqué de Barcelone : actions et mises à jours (25 janvier 2019) » en réponse aux éléments de l’avis du GAC des communiqués de Barcelone et de Panama.

      Fondements de la résolution 2019.01.27.18

      Le chapitre 12, article 12.2(a)(ix) des statuts constitutifs de l’ICANN autorise le GAC à « soumettre directement des sujets au Conseil d’administration, par le biais d’un commentaire ou d’un avis préalable, ou en recommandant une mesure spécifique, l’élaboration d’une nouvelle politique ou la révision des politiques actuelles, » Dans son communiqué de Barcelone (25 octobre 2018), le GAC a émis un avis auprès du conseil d’administration sur : les codes pays à deux caractères au second niveau et la protection des noms et sigles d’organisations intergouvernementales (OIG) dans les gTLD. Le GAC a également fourni un suivi aux conseils préalables sur le RGPD et le WHOIS, les candidatures Dot Amazon, la protection des désignations et identificateurs Croix rouge et Croissant rouge, et un suivi de la déclaration conjointe de l’ALAC et du GAC (Abu Dhabi, 2 novembre 2017). Les statuts constitutifs prévoient que le Conseil d’administration tient compte de l’avis du GAC en matière de politique publique pour la formulation et l’adoption de politiques. Dans le cas contraire, il est tenu d’en avertir le GAC en précisant ses motivations. Tout avis du GAC approuvé par consensus global du GAC (comme défini dans les statuts constitutifs) ne peut être rejeté que par un vote d’au moins 60 % du Conseil d’administration, et le GAC et le Conseil d’administration doivent ensuite essayer de trouver une solution réciproquement acceptable, en toute bonne foi, en temps voulu et de manière efficace.

      Le Conseil d’administration prend des mesures aujourd’hui sur tous les articles du Communiqué de Barcelone, y compris les éléments liés aux codes de pays à deux caractères au deuxième niveau ainsi que les mesures de protection des OIG. Le Conseil d’administration prend également des mesures sur les points concernant les codes de pays à deux caractères au deuxième niveau du communiqué du Panama, dont l’examen avait été reporté.

      Le Conseil d’administration continuera à reporter l’examen de cinq éléments du Communiqué de San Juan, notamment : quatre éléments de l’avis sur le RGPD et le WHOIS et l’un des éléments de l’avis relatif aux acronymes réservés aux OIG, en attendant d’autres discussions avec le GAC. Le Conseil d’administration décidera si une nouvelle action est nécessaire suite à ces discussions.

      Les actions du Conseil d’administration sont décrites dans la fiche de suivi datée du 25 janvier 2019.

      En adoptant sa réponse à l’avis du GAC émis dans le communiqué de Barcelone, le Conseil d’administration a examiné divers documents, y compris, mais sans s’y limiter, les documents suivants :

      L’adoption de l’avis du GAC comme fourni dans la fiche de suivi aura un impact positif sur la communauté, car cela aidera à résoudre les questions posées par l’avis du GAC sur les gTLD ainsi que d’autres problématiques. Aucun impact financier associé à l’adoption de cette résolution n’est prévu. L’approbation de la résolution n’aura pas de conséquences 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.

    4. Adoption de la politique de consensus de la GNSO concernant certains noms de la Croix-Rouge et du Croissant-Rouge au deuxième niveau du système des noms de domaine

      Attendu que, en mars 2017, l’organisation de soutien aux extensions génériques (« GNSO ») et le Comité consultatif gouvernemental (« GAC ») se sont engagés dans un dialogue facilité en toute bonne foi dans une tentative pour résoudre les divergences qui subsistent entre les recommandations de consensus des processus d’élaboration de politiques (« PDP ») originaux de la GNSO et l’avis du GAC concernant certains noms de la Croix rouge et du Croissant rouge.

      Attendu que, dans le cadre de ce dialogue facilité, le GAC et la GNSO ont noté certaines questions spécifiques, à savoir :

      1. Les considérations de politique publique associés à la protection d’identificateurs associés avec le mouvement de la Croix-Rouge internationale (« mouvement ») dans le système des noms de domaine ;
      2. Le fondement du GAC pour une protection permanente pour les termes les plus étroitement liés au mouvement et ses composantes respectives est ancrée dans les protections des dénominations « Croix Rouge », « Croissant-Rouge », « Lion-et-Soleil-Rouge », et de « Cristal Rouge » en vertu du droit international conventionnel et sous de multiples législations nationales ;
      3. La liste des noms des sociétés nationales de la Croix-Rouge et du Croissant-Rouge est une liste limitée et finie de noms spécifiques des sociétés nationales reconnues au sein du mouvement (http://www.ifrc.org/Docs/ExcelExport/NS_Directory.pdf) ;
      4. Il n’y a pas d’autres utilisations légitimes de ces termes ; et
      5. Le GAC a fourni des éclaircissements à la suite de l’achèvement du PDP de la GNSO via son communiqué de Singapour de mars 2014, sur le champ d’application fini de la liste spécifique de noms du mouvement pour lesquels des protections permanentes étaient demandées (https://gacweb.icann.org/download/attachments/28278854/Final%20Communique%20 % 20Singapour%202014.pdf?version=1&modificationDate=1397225538000&api=v2).

      Attendu que, à la suite de la discussion GAC-GNSO, le Conseil d’administration de l’ICANN a demandé que le Conseil de la GNSO envisage d’entamer le processus de la GNSO pour modifier les précédentes recommandations de politique de la GNSO concernant les noms complets des sociétés nationales de la Croix-Rouge et du Comité international de la Croix-Rouge et la Fédération internationale des Sociétés de la Croix-Rouge et du Croissant-Rouge, et une série restreinte et définie de variations de ces noms, dans les six langues officielles de l’Organisation des Nations Unies (Https://www.icann.org/resources/board-material/resolutions-2017-03-16-en#2.e.i).

      Attendu que, en mai 2017, le Conseil de la GNSO a décidé de convoquer à nouveau le Groupe de travail sur le PDP original pour examiner la demande du conseil d’administration (Https://gnso.icann.org/en/council/resolutions#20170503-071).

      Attendu que, en août 2018 ce groupe de travail sur le PDP a formulé six recommandations qui ont reçu le consensus global du Groupe de travail et les ont soumises au Conseil de la GNSO (Https://gnso.icann.org/en/issues/igo-ingo/red-cross-protection-policy-amend-process-final-06aug18-en.pdf), y compris un ensemble déterminé et limité de variations des noms de la Croix-Rouge et du Croissant-Rouge devant être réservé en vertu de la politique de consensus proposée (Https://gnso.icann.org/en/issues/igo-ingo/red-cross-identifiers-proposed-reservation-06aug18-en.pdf).

      Attendu que, en septembre 2018, le Conseil de la GNSO a voté à l’unanimité d’approuver toutes les recommandations consensuelles du PDP (Https://gnso.icann.org/en/council/resolutions#20180927-3) et en octobre 2018 a approuvé en outre la présentation d’un rapport de recommandations au Conseil de l’ICANN (Https://gnso.icann.org/en/council/resolutions#20181024-1).

      Attendu que, comme requis par les statuts de l’ICANN, une période de consultation publique a été ouverte en novembre 2018 afin d’offrir au public une occasion raisonnable de fournir des commentaires sur le projet de politique de consensus avant que le Conseil d’administration acte sur celui-ci, et que le GAC fournisse en temps opportun un avis sur toutes les préoccupations de politique publique.

      Attendu que, le Conseil a examiné les recommandations de la GNSO et tous les autres documents pertinents relatifs à cette question.

      Il est résolu (2019.01.27.19) que le Conseil adopte les recommandations finales du groupe de travail sur le PDP sur les Organisations internationales gouvernementales (OIG) et les organisations internationales non gouvernementales (OING) telles qu’adoptée par un vote unanime du Conseil de la GNSO le 27 septembre 2018.

      Il est résolu (2019.01.27.20) 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 adoptées conformes à 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.

      Fondements des résolutions 2019.01.27.19 – à 2019.01.27.20

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

      La GNSO a mené un PDP, concluant en novembre 2013, qui a examiné et mis au point certaines recommandations politiques pour protéger certains identificateurs associés avec le mouvement de la Croix-Rouge et du Croissant-Rouge. Les recommandations de la GNSO qui étaient conformes aux avis du GAC sur ce sujet ; c’est-à-dire relatives aux termes spécifiques de « Croix Rouge », « Croissant-Rouge », de « Cristal Rouge » et « Lion et Soleil Rouge » ont été adoptées par le Conseil en avril 2014 (Http://www.icann.org/en/groups/board/documents/resolutions-30apr14-en.htm#2.a). Suite au travail de mise en œuvre par l’organisation de l’ICANN et les volontaires de la Communauté, ces quatre termes spécifiques sont maintenant absents de délégation au premier et le deuxième niveau du DNS, dans les six langues officielles de l’Organisation des Nations Unies, dans le cadre d’une politique de consensus qui est entrée en vigueur en janvier 2018.

      Le Conseil n’avait pas approuvé les autres recommandations de politique de la GNSO de 2013 qui concernaient d’autres identificateurs de la Croix-Rouge et du Croissant-Rouge, p. ex. les noms complets de toutes les Sociétés nationales du mouvement de la Croix-Rouge et ceux du mouvement international de la Croix-Rouge et du Croissant-Rouge, le Comité international de la Croix-Rouge et la Fédération internationale des Sociétés de la Croix-Rouge et du Croissant-Rouge. Le Conseil n’avait pas approuvé ces recommandations de politique à cette époque pour permettre d’autres discussions entre le Conseil, la GNSO, le GAC et la communauté sur les contradictions entre les recommandations de politique de la GNSO et l’avis du GAC. Au cours des mois suivants, le conseil d’administration a facilité le dialogue entre les groupes sur un chemin possible vers l’avant. À la suite de la conclusion du dialogue facilité entre le GAC et la GNSO en mars 2017, le Conseil de la GNSO a reconvoqué le Groupe de travail sur le PDP original pour examiner d’éventuelles modifications de ses précédentes recommandations concernant ces identificateurs spécifiques.

      En septembre 2018, le Conseil de la GNSO a approuvé à l’unanimité les recommandations modifiées de politique présentées dans le rapport final du Groupe de travail sur le PDP. Avec l’approbation unanime du Conseil de la GNSO des recommandations modifiées de politique, le Conseil d’administration est maintenant en train de prendre des mesures pour adopter le texte révisé des recommandations de politique de consensus conformément à la procédure décrite dans les statuts de l’ICANN.

      Quelle est la proposition à l’étude ?

      Les recommandations du PDP sont que certains noms spécifiques des sociétés de la Croix-Rouge et du Croissant-Rouge ainsi qu’une liste de variantes convenues et autorisées de ces noms soient impossibles à déléguer au deuxième niveau du DNS, dans les six langues officielles de l’Organisation des Nations Unies. Les recommandations du PDP comprennent un processus spécifique et documenté et les critères pour corriger des erreurs trouvées dans la liste convenue des noms et variantes, ainsi que pour l’ajout ou la suppression d’entrées dans cette liste. La politique adoptée permettra de compléter la politique de consensus existant sur la protection aux premier et deuxième niveaux des termes « Croix Rouge », « Croissant-Rouge », de « Cristal Rouge » et « Lion et Soleil Rouge » dans les six langues officielles de l’Organisation des Nations Unies.

      Pour plus de clarté, les recommandations du PDP n’incluent pas les propositions de protection des acronymes associés au Mouvement international de la Croix-Rouge, qui reste une question en suspens depuis le PDP original de la GNSO en 2013, qui a débouché sur des recommandations qui sont incompatibles avec l’avis du GAC concernant ces acronymes.

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

      Le groupe de travail sur le PDP reconstitué effectue ses travaux conformément au manuel du PDP de la GNSO et les directives du groupe de travail, qui comprennent des dispositions relatives à une large représentation de la communauté. Le Groupe de travail était composé de représentants des diverses parties de la GNSO et de la communauté de l’ICANN, y compris des représentants de la Croix-Rouge. Le rapport initial du groupe de travail a été publié pour consultation publique en juin 2018, à la suite de laquelle le groupe a examiné tous les commentaires reçus dans l’élaboration de ses recommandations finales, qui ont toutes fait l’objet d’un consensus global du Groupe de travail. Avant le vote du Conseil de la GNSO sur le rapport final, le président du Groupe de travail a consacré une réunion avec les membres de la communauté qui avaient exprimé certaines préoccupations au sujet du projet de recommandations. Le Conseil de la GNSO a voté à l’unanimité pour approuver toutes les recommandations en septembre 2018.

      Les recommandations de politiques approuvées par le Conseil de la GNSO ont été publiées pour consultation publique en novembre 2018 et le GAC a été notifié de l’action du Conseil.

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

      Les préoccupations possibles au sujet de la liberté d’expression ont été soulevées concernant la réservation des noms des Croix Rouge et Croissant Rouge au deuxième niveau du DNS, ainsi que l’élaboration par le Groupe de travail des critères et d’un processus pour l’ajout de nouveaux noms et variantes à la liste au lieu de recommander une liste fixe. La communauté recherche également des éclaircissements sur le mécanisme de mise en œuvre de la politique proposée (p. ex est-ce que les contrats de l’ICANN Org avec ses parties contractantes devront être modifiés). Le Conseil comprend que le Groupe de travail croit qu’il a abordé ces préoccupations dans l’élaboration de ses recommandations de politique de consensus définitives.

      D’autres observations de la communauté appuient la politique proposée, indiquant que la politique publique doit fournir des protections adéquates pour la Croix-Rouge contre les utilisations malveillantes de ses noms et reconnaître ses variantes, ainsi que le fait que les protections recommandées sont ancrées dans le droit international humanitaire et plusieurs lois nationales.

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

      Le Conseil a examiné le rapport final du Groupe de travail et la liste recommandée de protection des noms de la Croix-Rouge (https://gnso.icann.org/sites/default/files/file/field-file-attach/red-cross-protection-policy-amend-process-final-06aug18-en.pdf et Https://gnso.icann.org/sites/default/files/file/field-file-attach/red-cross-identifiers-proposed-reservation-06aug18-en.pdf), le rapport de recommandations du Conseil de la GNSO (Https://gnso.icann.org/en/drafts/reconvened-red-cross-recommendations-14oct18-en.pdf), un résumé des commentaires du public reçus (Https://www.icann.org/en/system/files/files/report-comments-red-cross-names-consensus-policy-04jan19-en.pdf) et l’avis du GAC pertinent sur cette question (Https://gac.icann.org/).

      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 consensus global du groupe de travail et le soutien unanime du conseil de la GNSO. Comme il est indiqué dans les statuts de l’ICANN (Annexe A, art. 9.a.), « toute recommandation du PDP approuvée par un vote à la majorité qualifiée de la GNSO sera adoptée par le Conseil à moins que, par un vote de plus des deux tiers (2/3) du Conseil, celui-ci estimait que cette politique n’est pas dans le meilleur intérêt de l’ICANN ou de sa communauté. »

      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. Dans ce contexte, le Communiqué de Barcelone d’octobre 2018 du GAC a exprimé l’espoir que le Conseil adoptera les recommandations de la GNSO.

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

      L’adoption par le Conseil de ces recommandations va résoudre le problème, en souffrance depuis 2013, des incohérences entre l’avis du GAC et la politique antérieure de la GNSO sur ces noms spécifiques de la Croix-Rouge et du Croissant-Rouge. Cela signifie que la protection provisoire précédemment mise en place par le Conseil concernant ces noms sera remplacée par la politique de consensus quand elle sera effective, menant à une plus grande clarté quant à l’ampleur de la protection de ces noms pour les parties contractantes de l’ICANN et la communauté au sens large.

      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 ?

      Hormis tous frais financiers ou liés aux autres ressources qui pourraient survenir durant les travaux sur la mise en œuvre de la politique adoptée, aucune répercussion financière ou autre sur l’ICANN, la communauté ou le public n’est envisagée.

      Y a-t-il des implications sur la sécurité, la stabilité ou la 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.

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

      Cette affaire concerne le processus de politique de la GNSO, comme défini et décrit par les statuts de l’ICANN et les procédures de fonctionnement de la GNSO. Toutes les exigences de consultation publique dans le cadre de ces processus ont été respectées.

    5. Appartenance au comité du conseil d’administration et changements de leadership

      Attendu que, Chris Disspain est un membre du Conseil et l’actuel président du comité du Conseil d’administration chargé des mécanismes de responsabilité (BAMC)

      Attendu que, Leon Sanchez est un membre actuel du Conseil d’administration et membre du BAMC.

      Attendu que, pour faciliter la transition à la direction du BAMC, le comité de gouvernance du Conseil (BGC) a recommandé au Conseil d’administration de nommer promptement León Sanchez au poste de président du BAMC et de conserver M, DIsspain comme membre du BAMC.

      Attendu que, Matthew Shears a exprimé un intérêt à devenir membre du comité du Conseil d’administration chargé de l’efficacité organisationnelle (OEC) et le BGC a recommandé au Conseil d’administration de nommer immédiatement M. Shears comme membre de l’OEC.

      Il est résolu (2019.01.27.21) que le Conseil nomme León Sanchez président du BAMC et conserve Chris disspain comme membre du BAMC, à effet immédiat.

      Il est résolu (2019.01.27.22) que le Conseil nomme Matthew Shears membre de l’OEC, à effet immédiat.

      Fondements des résolutions 2019.01.27.21 – à 2019.01.27.22

      Le Conseil s’est engagé à faciliter une transition sans heurt au sein de la direction de ses Comités dans le cadre de discussions continues sur la planification de la relève. À cette fin, le Comité du Conseil d’administration chargé des mécanismes de responsabilité (BAMC) a suggéré que son président actuel, Chris Disspain, se retire de la présidence (mais reste membre) et que le Conseil d’administration nomme León Sanchez président du BAMC. En tant que membre du BAMC, M. Disspain travaillera avec M. Sanchez au cours d’une période de transition.

      Étant donné que le Comité de gouvernance du Conseil (BGC) est chargé de recommander les candidatures, il a discuté de la proposition du BAMC et a recommandé au Conseil d’administration de nommer León Sanchez au poste de président du BAMC et conserve M. DIsspain membre de ce même comité, à effet immédiat. Le Conseil d’administration est d’accord avec les recommandations du BGC.

      Le Conseil s’est également engagé à faciliter la composition des comités du conseil d’administration en accord avec le Comité du Conseil d’administration et les procédures de sélection des dirigeants. Le BGC a considéré l’intérêt exprimé par Matthew Shears à rejoindre le comité d’efficacité organisationnelle et a recommandé au Conseil d’approuver cette nomination. Le Conseil d’administration est d’accord avec les recommandations du BGC.

      La mesure est conforme à l’intérêt public et dans la poursuite de la mission de l’ICANN, car il est important que les comités du conseil d’administration, pour accomplir les tâches assignées par le Conseil en conformité avec les statuts de l’ICANN et les chartes des comités, aient mis en place des plans de relève appropriés afin d’assurer la continuité de la direction de ces comités. En outre, il est tout aussi important que la composition des comités du conseil d’administration soit établie en vertu des procédures de sélection des dirigeants et du Comité du Conseil. Cette mesure n’a aucun impact financier sur l’ICANN et n’aura pas d’impact négatif 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.

    6. Considération de la demande de réexamen 16-11 : Travel Reservations SRL, Famous Four Media Limited (et son candidat affilié dot Hotel Limited), Fegistry LLC, Minds + Machines Group Limited, Spring McCook, LLC, and Radix FZC (et son candidat affilié dot Hotel Inc.) (.HOTEL)

      Attendu que, Travel Reservations SRL, Minds + Machines Group Limited, Radix FZC (et sa filiale candidate dotHotel Inc.), (collectivement les requérants) ont présenté une candidature standard pour. HOTEL, qui a été placée dans un ensemble conflictuel avec d’autres candidatures .HOTEL. Un autre requérant, HOTEL Top-Level-Domain S.a.r.l. (HTLD), a présenté une candidature communautaire pour .HOTEL.

      Attendu que, HTLD a participé à l’évaluation de la priorité communautaire (CPE) et l’a emporté.

      Attendu que, le 9 août 2016, le Conseil a adopté les résolutions 2016.08.09.14 et 2016.08.09.15 (résolutions de 2016), qui demande à l’organisation de l’ICANN d’aller de l’avant avec le traitement de la candidature communautaire gagnante pou le gTLD .HOTEL (candidature de HTLD) présentée par HTLD.

      Attendu que, les requérants ont présenté une demande de réexamen 16-11 demandant de reconsidérer les résolutions de 2016.

      Attendu que, alors que la demande 16-11 était en cours, le Conseil d’administration a demandé à l’organisation de l’ICANN d’entreprendre une révision des processus CPE (révision du processus CPE). Le Comité de gouvernance du Conseil d’administration (BGC) a déterminé que les demandes de réexamen en cours concernant le processus CPE, y compris la demande 16-11, seraient en attente jusqu’à la fin de la révision du processus CPE.1

      Attendu que, le 13 décembre 2017, l’organisation ICANN a publié trois rapports sur la révision du processus CPE (les rapports sur la révision du processus CPE).

      Attendu que, le 15 mars 2018, le Conseil a voté les résolutions 2018.03.15.08 à 2018.03.15.11, dans lesquels le Conseil d’administration a reconnu et accepté les constatations énoncées dans les rapports de révision du processus CPE ; a déclaré que la révision du processus CPE était terminée ; a conclu que, sur la base des constatations provenant des rapports de révision du processus CPE il n’y aurait aucune révision ou modification du processus CPE pour la série actuelle du programme des nouveaux gTLD ; et a chargé le comité du Conseil d’administration chargé des mécanismes de responsabilité (BAMC) d’aller de l’avant en reprenant l’examen du reste des demandes de réexamen relatives au processus CPE qui avaient été mises en attente jusqu’à l’achèvement de la révision du processus CPE.

      Attendu que, conformément aux résolutions 2018.03.15.08 à 2018.03.15.11, le BAMC a invité les requérants à faire une présentation téléphonique au BAMC à l’appui de leur demande 16-11, ce que les requérants ont fait le 19 juillet 2018. Le BAMC a également invité les requérants à soumettre d’autres documents écrits en réponse aux rapports de la révision du processus CPE.

      Attendu que, le BAMC a soigneusement examiné le bien-fondé de la demande 16-11 et tous les documents pertinents, et a recommandé que la demande 16-11 soit rejetée parce que le Conseil a adopté les résolutions 2016 fondées sur des renseignements exacts et complets. Le BAMC a également recommandé au Conseil de rejeter la demande 16-11, car il n’y a pas de preuves à l’appui de l’affirmation des requérants que le conseil avait omis de prendre en considération le prétendu « avantage indu » qu’HTLD aurait obtenu sur la base de la configuration du portail, il n’y a également aucune preuve que le Conseil avait fait preuve de discrimination contre les requérants.

      Attendu que, le Conseil a examiné attentivement la recommandation du BAMC concernant la demande 16-11 et tous les documents pertinents liés à la demande, dont la réfutation du requérant, et le Conseil accepte la recommandation du BAMC et conclut que la réfutation n’offre aucun argument ni élément de preuves à l’appui de sa demande de réexamen.

      Il est résolu (2019.01.27.23) que le Conseil d’administration adopte la recommandation du BAMC concernant la demande 16-11.

      Fondements de la résolution 2019.01.27.23

      1. Bref résumé et recommandation

        L’ensemble des faits est énoncé dans la recommandation du BAMC relative à la demande 16-11 (Recommandation du BAMC), que le Conseil d’administration a examinée et prise en compte et qui est jointe à ces présentes.

        Le 16 novembre 2018, le BAMC a évalué la demande 16-11 et tous les documents pertinents et a recommandé au Conseil d’administration de rejeter la demande 16-11 parce que le Conseil d’administration a adopté les résolutions 2016 sur la base de renseignements exacts et complets. Le BAMC a également recommandé au Conseil de rejeter la demande 16-11, car il n’y a pas de preuves à l’appui de l’affirmation des requérants que le conseil avait omis de prendre en considération le prétendu « avantage indu » qu’HTLD aurait obtenu sur la base de la configuration du portail, il n’y a également aucune preuve que le Conseil avait fait preuve de discrimination contre les requérants.

        Le 30 novembre 2018, le requérant a proposé une réfutation de la recommandation du BAMC (réfutation). Le Conseil note que la réfutation n’est pas à considérer en vertu des statuts constitutifs applicables à la demande 16-11, qui sont ceux définis en 2016 et qui étaient en vigueur lorsque la demande 16-11 a été déposée.2 Néanmoins, le Conseil a examiné les arguments des requérants dans cette réfutation et conclut qu’ils ne justifiaient pas un réexamen pour les raisons énoncées ci-dessous.

      2. Problématique

        Les questions sont de savoir si l’adoption par le Conseil des résolutions de 2016 est survenue : (i) sans tenir compte d’informations importantes ; ou (ii) sur la base de documents faux ou inexacts.

        Ces questions sont examinées sous les normes applicables aux demandes de réexamen en vigueur au moment où cette demande 16-12 a été soumise. Ces normes sont abordées plus en détail dans la recommandation du BAMC.

      3. Analyse et fondements

        1. Le Conseil a adopté les résolutions de 2016 après avoir examiné tous les documents d’informations, sans recours à des renseignements faux ou inexacts.

          Les requérants suggèrent que le réexamen des résolutions 2016 est justifié parce que l’ICANN org a omis d’enquêter comme il convient sur la configuration du portail et a omis de prendre en compte les présumées actions relatives à la configuration du portail. Plus précisément, les requérants font valoir que l’ICANN org n’a pas vérifié l’affirmation par Dirk Kirschenowski, la personne dont les identificateurs ont été utilisés pour accéder à des informations confidentielles des autres utilisateurs autorisés du portail des nouveaux gTLD, qu’il n’avait pas et ne fournirait pas les renseignements auxquels il a eu accès à HTLD ou son personnel. Le BAMC a conclu, et le Conseil a accepté que cet argument ne justifie pas un réexamen parce que les requérants n’ont pas identifié de renseignements faux ou trompeurs que le Conseil aurait invoqués, ou des documents que le conseil aurait omis de prendre en considération eu égard à la configuration du portail lors de l’adoption des résolutions 2016.

          Tout d’abord, le BAMC a déterminé, et le Conseil a accepté que l’ICANN org a entrepris une analyse rigoureuse et complète de la configuration du portail et les questions soulevées par les requérants en ce qui concerne la configuration du portail. Les résultats de l’enquête ont été partagés avec le Conseil d’administration de l’ICANN et ont été soigneusement examinés par le Conseil dans le cadre de son adoption des résolutions de 2016. Le BAMC a noté que, dans son enquête, l’ICANN org n’a découvert aucune preuve de ce qui suit : (i) les informations que M. Krischenowski pourrait avoir obtenues via le portail ont été utilisées afin de soutenir la candidature de HTLD ; ou (ii) les informations obtenues par M. Krischenowski ont permis à la candidature de HTLD d’être retenue lors de la CPE. En outre, l’enquête de l’ICANN a révélé qu’au moment où M. Krischenowski a accédé à des informations confidentielles, il n’était pas directement lié à la candidature HTLD à titre de contact autorisé ou actionnaire, dirigeant ou directeur. Au contraire, M. Krischenowski était actionnaire à 50 % et directeur général de HOTEL Top-Level-Domain GmbH, Berlin (GmbH Berlin), qui était actionnaire minoritaire (48,8 %) de HTLD. Monsieur Philipp Grabensee, le seul directeur général de HTLD, a informé l’ICANN org que M. Krischenowski « n’était pas un employé » de HTLD, mais que M. Krischenowski agissait comme consultant sur la candidature de HTLD au moment où elle a été présentée en 2012. Monsieur Grabensee a de plus vérifié que HTLD « avait seulement appris [l’accès aux données de M. Krischenowski] le 30 avril 2015 dans le cadre de l’enquête de l’ICANN. » Monsieur Grabensee a déclaré que les services commerciaux entre M. Krischenowski, consultant, et HTLD ont été stoppés le 31 décembre 2015.3

          Deuxièmement, contrairement aux affirmations des requérants, le BAMC a déterminé que l’ICANN org a vérifié l’affirmation de M. Krischenowski que lui et ses associés n’avaient pas, et ne voulaient pas partager les informations confidentielles auxquelles il avait eu accès sur la base de la configuration du portail avec HTLD. L’ICANN org a également confirmé auprès de HTLD qu’ils n’avaient pas reçu de renseignements confidentiels de M. Krischenowski ou de ses associés obtenus à partir de la configuration du portail. Comme discuté dans les fondements des Résolutions 2016, cette information a été examinée par le Conseil lors de l’adoption des résolutions.4 Comme le Conseil l’a noté dans les fondements des résolutions 2016, même si M. Krischenowski (ou ses associés) avait obtenu les documents commerciaux sensibles appartenant aux requérants, cela n’aurait pas eu d’incidence sur le processus de CPE pour la candidature de HTLD Les requérants n’ont pas expliqué comment des documents confidentiels appartenant aux autres candidats pour. HOTEL pourraient avoir eu un impact sur les critères CPE, qui ne tiennent pas compte d’informations confidentielles d’autres entités. Bien que l’accès de M. Krischenowski aux documents se soit produit avant le rapport de la CPE en juin 2014, HTLD n’a pas cherché à modifier sa candidature au cours de la CPE, et n’a fourni aucune documentation qui pourrait avoir été examinée par le panel CPE.5 Il n’y a aucune preuve que le panel CPE ait eu une interaction avec M. Krischenowski durant le processus de CPE, et il n’y a donc aucune raison de croire que le panel CPE n’ait jamais reçu les renseignements confidentiels que M. Krischenowski a obtenus.6

          Pour ces raisons, qui sont examinées plus en détail dans la recommandation du BAMC et intégrées par renvoi aux présentes, le BAMC a déterminé, et le Conseil a accepté que les requérants n’ont pu identifié une quelconque information fausse ou trompeuse que le Conseil aurait invoquée, ou des informations que le conseil aurait omis de prendre en considération eu égard à la configuration du portail lors de l’adoption des résolutions 2016. La décision du Conseil de permettre à la candidature de HTLD de progresser a été prise à la suite d’une enquête complète, et a été bien réfléchie et est compatible avec les règlements et statuts constitutifs de l’ICANN org. En particulier, pour parvenir à sa décision selon laquelle la candidature de HTLD ne devait pas être exclue, le Conseil a examiné attentivement les résultats de l’examen légal de l’ICANN org et de l’enquête sur la configuration du portail et les réclamations des requérants concernant la prétendue incidence de la configuration du portail sur le CPE de la candidature de HTLD

        2. Le Conseil ne s’est pas appuyé sur des renseignements faux ou trompeurs en acceptant la déclaration du Panel IRP Despegar.

          Bien que la demande 16-11 conteste la conduite du Conseil se rapportant aux résolutions 2016, les requérants semblent également contester l’acceptation par le conseil d’administration de la Déclaration du Panel IRP Despegar. En particulier, les requérants affirment que « le panel IRP Despegar et al. s’est fondé sur des informations fausses et inexactes, « comme lorsque le Conseil de l’ICANN a accepté la Déclaration du panel IRP Despegar et al. il s’appuyait sur les mêmes informations fausses et inexactes. »7

          Initialement, le Conseil est d’accord avec la conclusion du BAMC que l’affirmation des requérants est frappée de prescription. La résolution du Conseil concernant la déclaration du Panel IRP Despegar a été publiée le 10 mars 2016.8 La demande 16-11 a été soumise le 25 août 2016, plus de cinq mois après l’acceptation par le Conseil de la Déclaration du Panel IRP Despegar, et bien au-delà du délai de 15 jours autorisé pour demander le réexamen d’une décision du Conseil.9

          1. Les réclamations des requérants concernant les déclarations du panel IRP Corn Lake et Dot Registry ne prouvent pas leurs allégations de discrimination.

            Même si les requérants avaient contesté en temps opportun la résolution du Conseil concernant la déclaration du Panel IRP Despegar, le Conseil convient avec le BAMC que les réclamations des requérants ne justifient pas un réexamen. Le requérant cite la déclaration du panel IRP publiée dans dot Registry, LLC v. ICANN (Déclaration du panel IRP dot Registy) pour appuyer leur affirmation que la déclaration du panel de l’IRP Despegar était fondée « sur la fausse prémisse que les déterminations du [fournisseur CPE] sont présumées finale et sont réalisées indépendamment par le [fournisseur CPE], sans la participation active de l’ICANN. » 10 En particulier, les requérants affirment que la déclaration du panel de l’IRP Dot Registry démontre que « l’ICANN a communiqué avec les évaluateurs qui identifient la note de chaque CPE, » 11 et donc le panel IRP Despegar a utilisé de fausses informations (c’est-à-dire la représentation de l’ICANN org dans sa réponse à la demande de DIDP de 2014, indiquant que l’ICANN org ne s’engage pas dans des communications avec les évaluateurs individuels qui sont impliqués dans la notation des CPE, ce qui faisait l’objet de la demande 14-39), quand il a constaté que l’ICANN org était la partie gagnante. En conséquence, les requérants suggèrent que le Conseil d’administration de l’ICANN s’est également appuyé sur des informations erronées lorsqu’il a accepté la déclaration de Panel IRP Despegar. Les requérants soutiennent également qu’ils « se situent au même niveau » que les plaignants Dot Registry, et donc si le Conseil refuse de dédommager les requérants alors qu’il a dédommagé les plaignants Dot Registry, alors le Conseil d’administration discrimine les requérants en contradiction avec les statuts constitutifs de l’ICANN. Le BAMC a conclu, et le Conseil a accepté que la Déclaration IRP dot Registry et la réponse du Conseil ne correspondent pas à la demande des requérants de réexamen pour les raisons suivantes.

            Tout d’abord, contrairement à l’affirmation des requérants, le Panel de l’IRP Dot Registry n’a pas trouvé que l’ICANN org s’était engagée dans une communication avec les évaluateurs CPE qui ont participé à la notation de la CPE. Deuxièmement, les déclarations faites par un panel de l’IRP ne peuvent pas être sommairement appliquées dans le cadre d’un IRP entièrement distinct, non lié, et différent. L’IRP Dot Registry concerne. LLC,. INC et. LLP, alors que l’IRP Despegar concerne. HOTEL. Différentes questions ont été examinées dans chaque IRP, basées sur différents arguments présentés par des parties différentes concernant des applications différentes et des situations factuelles non apparentées. En tant que tel, il n’y a pas de preuves à l’appui de la tentative des requérants d’appliquer les conclusions de la déclaration IRP Dot Registry à l’IRP Despegar.

            De même, le BAMC a conclu, et le Conseil a accepté que la citation des requérants sur l’acceptation par le Conseil de la déclaration finale dans Corn Lake, LLC v. ICANN, (Déclaration IRP Corn Lake) et de la décision « d’étendre sa procédure d’examen final afin d’inclure l’examen de la détermination de l’expert en charité de Corn Lake » 12 ne justifie pas un réexamen. Comme cela a été le cas avec l’IRP dot Registry, les circonstances de l’IRP Corn Lake et de la décision subséquente du Conseil concernant .CHARITY impliquaient différents faits et considérations distinctes spécifiques aux circonstances de la candidature Corn Lake. En tant que telle, l’action du Conseil n’équivaut pas ici à un traitement discriminatoire ou incohérent ; c’est plutôt un exemple de la manière dont le Conseil doit « pouvoir utiliser des distinctions nuancées entre les différentes [candidatures] gTLD, »13 et est compatible avec les statuts constitutifs de l’ICANN.

          2. La révision du processus CPE confirme que l’ICANN org n’exerce pas une influence indue sur le fournisseur CPE en ce qui concerne les CPE effectuées.

            Le BAMC a conclu, et le Conseil a accepté que la suggestion des requérants que l’ICANN org exerçait une influence indue sur le fournisseur CPE dans son exécution de CPE ne justifie pas un réexamen.14 En effet, comme le BAMC l’a correctement fait remarquer, cet argument a déjà été abordé par le Conseil dans les résolutions de 2018.15

            En bref, le rapport sur le 1er champ d’application de la révision du processus CPE confirme qu’« il n’y a aucune preuve que l’ICANN org a eu une influence indue sur le fournisseur CPE au sujet des rapports CPE issus par le fournisseur CPE ou s’est engagée dans une quelconque irrégularité dans le processus de CPE », y compris en ce qui a trait à la candidature de HTLD16 Les requérants croient que le rapport sur le 1er champ d’application démontre que « le fournisseur CPE n’était pas indépendant de l’ICANN. « Toute influence exercée par l’ICANN dans le cadre de la CPE est contraire à la politique, et donc abusive. »17 Les requérants n’identifient pas la « politique » dont ils font mention, mais dans tous les cas, leur désaccord avec les conclusions du rapport sur le 1er champ d’application ne justifie pas un réexamen. C’est parce que les requérants ne contestent pas que, lorsque l’ICANN org a apporté des commentaires sur le fournisseur CPE, cet apport n’impliquait pas de contestation des conclusions de ce fournisseur CPE, mais était plutôt un moyen de s’assurer que les rapports CPE étaient clairs et que « les conclusions du fournisseur CPE » — pas les conclusions de l’ICANN org — étaient « suffisamment motivées. »18 Les requérants citent également « des appels téléphoniques entre l’ICANN et le fournisseur CPE pour débattre de « différentes questions », indiquant que ces appels « montrent que le fournisseur n’a pas été libre de l’influence extérieure de l’ICANN org » et n’était donc pas indépendant.19 Aucun de ces faits ne démontre que le fournisseur CPE n’était pas « indépendant » ou que l’ICANN org exerçait une influence indue sur le fournisseur CPE. Ces types de communications démontrent au contraire que l’ICANN org a protégé l’indépendance du fournisseur CPE en se concentrant sur la manière de garantir que les conclusions de ce fournisseur CPE étaient claires et bien raisonnées, plutôt que de diriger le fournisseur CPE pour aboutir à une conclusion particulière. Cet argument ne justifie donc pas un réexamen. Par conséquent, le BAMC a conclu, et le Conseil a accepté que parce que le rapport sur le 1er champ d’application démontre que l’ICANN org n’a pas exercé une influence indue sur le fournisseur CPE et sur le processus de CPE, il réfute l’affirmation des requérants que « le panel IRP Despegar et al. a reçu des renseignements incomplets et trompeurs », affirmation qui est fondée uniquement sur l’hypothèse que l’ICANN org a exercé une influence indue dans le processus de CPE.20

          3. Les requérants n’ont pas démontré que l’ICANN org était obligée de produire les communications entre l’ICANN et le panel CPE.

            Le Conseil est d’accord avec la conclusion du BAMC indiquant qu’un réexamen n’est pas justifié parce que, contrairement à ce que prétendent les requérants, le Panel de l’IRP Despegar n’a pas ordonné à l’ICANN org de produire des documents entre l’ICANN org et le fournisseur CPE. Le BAMC a noté que ce que l’ICANN org n’a pas reçu l’ordre du panel IRP de produire un quelconque document dans l’IRP Despegar, et donc aucun document qui refléterait les communications entre l’ICANN org et le panel CPE. Et aucune politique ou procédure n’a exigé de l’ICANN org de volontairement produire des documents au cours de l’IRP Despegar ou par la suite.21 En revanche, au cours de l’IRP Dot Registry, ce panel a ordonné à l’ICANN org de produire tous les documents reflétant « la considération apportée par l’ICANN aux travaux effectués par le [fournisseur CPE] dans le cadre de la candidature Dot Registry » et « les actes effectués et les décisions prises par l’ICANN à propos des travaux effectués par le [fournisseur CPE] dans le cadre de la candidature Dot Registry. » 22 Les communications de l’ICANN org avec les panels CPE pour. INC,. LLC et. LLP tombaient dans le champ d’application de telles demandes, et ont donc été produites. En fin de compte, l’ICANN org a agi en conformité avec les politiques et procédures applicables, y compris les statuts de l’ICANN, dans les deux cas.23

          4. Les requérants n’ont pas démontré qu’une nouvelle CPE de la candidature HTLD était appropriée.

            Sans identifier les critères de cette CPE particulière, les requérants demandent au Conseil d’administration de « garantir une révision sérieuse de la CPE concernant .HOTEL, assurant une cohérence d’approche avec sa gestion de la [déclaration du panel IRP] de Dot Registry. »24 Le BAMC a déterminé, et le Conseil a accepté que dans la mesure où les requérants font valoir que le résultat de l’analyse CPE de la candidature HTLD est incohérent comparée aux autres candidatures CPE, cet argument a déjà été traité dans le champ d’application 2 de la révision du processus CPE. Ici, « FTI n’a trouvé aucune preuve que le processus d’évaluation du fournisseur CPE ou les rapports s’écartaient des directives applicables ; pas plus que FTI a observé de cas où le fournisseur CPE aurait appliqué les critères CPE de manière incohérente. » 25 En outre, pour les raisons exposées ci-dessus et en détail dans la recommandation du BAMC, le Conseil conclut que ni le CPE .HOTEL ni les résolutions 2016 ne prouvent de traitement discriminatoire ou incohérent à l’égard des requérants. Comme tel, cet argument ne justifie pas un réexamen.

        3. Les résolutions 2018 sont compatibles avec la mission, les engagements, les valeurs fondamentales et les politiques établies de l’ICANN.

          Les critiques des requérants sur les résolutions 2018 se concentrent sur la transparence, la méthodologie et la portée des révisions du processus CPE. Aucune ne justifie un réexamen. Le BAMC a trouvé, et le Conseil a accepté que le BAMC et le Conseil ont abordé les préoccupations des requérants concernant les résolutions 2018 dans sa recommandation concernant la demande 18-6,26 que le Conseil a adopté le 18 juillet 2018.27 Les justifications énoncées par le BAMC et le Conseil dans la réponse à la demande 18-6, sont intégrées par renvoi aux présentes.

        4. La réfutation ne présente aucun argument ou fait justifiant le réexamen.

          Comme sujet initial, la demande 16-11 a été soumise conformément aux statuts constitutifs du 11 février 2016, voir la discussion ci-dessus, qui ne conduit pas à une réfutation de la recommandation du BAMC.28 Néanmoins, le Conseil d’administration a pris en considération la réfutation des requérants et conclut que ces derniers n’avaient pas fourni de nouveaux arguments ou faits justifiant le réexamen.

          1. Les statuts constitutifs du 11 février 2016 régissent la demande 16-11.

            Les requérants font valoir que le Conseil devrait examiner la demande 16-11 en vertu des normes de révision énoncées dans les statuts constitutifs du 18 juin 2018, c’est-à-dire, la version des statuts constitutifs en vigueur au moment de la recommandation du BAMC, plutôt que la version du 11 février 2016 qui était en vigueur lorsque la demande 16-11 a été soumise le 25 août 2016. Toutefois, les statuts constitutifs du 18 juin 2018 n’existaient pas lorsque les requérants ont formulé la demande 16-11 et le Conseil n’a pas indiqué la possibilité de rétroactivité lorsqu’il a approuvé la version des statuts constitutifs du 18 juin 2018 ; en conséquence, les statuts constitutifs du 18 juin 2018 n’ont aucun effet rétroactif. En effet, le formulaire de demande de réexamen que les requérants ont présenté fait référence aux normes de réexamen prévues dans les statuts constitutifs du 11 février 2016, stipulant aux requérants que, pour discuter des actions du Conseil, « ils se doivent d’identifier des informations qui existaient [à] la date de la décision et n’ayant pas été prises en considération par le Conseil pour demander une demande de réexamen. » (Voir la demande 16-11, §. 8, p. 7.) Par conséquent, le BAMC a correctement examiné la demande 16-11 dans le cadre des statuts constitutifs du 11 février 2016, qui étaient en vigueur lorsque les requérants ont formulé la demande 16-11.

          2. Les contestations des statuts constitutifs faites par les requérants sont tardives.

            Les requérants font valoir que « les exigences formelles de l’article 4(2)(q) [des statuts constitutifs du 18 juin 2018] et les circonstances de ce cas créent un déséquilibre injustifié qui empêche les requérants de participer à la procédure de réexamen d’une façon significative » parce que le BAMC a émis une recommandation de 33 pages « presque quatre mois » après la présentation téléphonique des requérants concernant la demande 16-11, lorsque (en vertu des statuts constitutifs actuels) les réfutations doit être déposées dans les 15 jours après les publications par le BAMC de ses recommandations et ne peut pas dépasser 10 pages. (Réfutation, p. 1.) Comme on l’a noté ci-dessus, la version des statuts constitutifs du dispositif ne fournissent pas au requérant le droit de soumettre une réfutation, donc, un réexamen n’est pas justifié compte tenu du désaccord apparent des requérants avec les délais qui régissent les réfutations en vertu de l’actuelle (inapplicable) version des statuts constitutifs.29 en outre, les requérants ont participé de façon significative dans le processus de réexamen : les requérants ont fait une présentation lors d’une audience téléphonique concernant la demande 16-11 (réfutation p. 1) ; et, comme indiqué dans la recommandation du BAMC, les requérants ont formulé — et le BAMC a examiné — sept lettres à l’appui de la demande 16-11.30 Les requérants ont maintenant également soumis une réfutation à l’appui de la demande 16-11, que le Conseil d’administration a considérée. En conséquence, les requérants n’ont pas démontré qu’ils ont été empêchés de participer de façon « significative » au processus de cette demande de réexamen.

          3. Le Conseil d’administration avait examiné les actions de Mme Ohlmer lorsqu’il a adopté les résolutions 2016.

            Les requérants font valoir que le « Conseil a ignoré le rôle de [Katrin] Ohlmer » (réfutation, p. 3) dans la problématique de la configuration du portail. Les requérants prétendent que Mme Ohlmer était PDG de HTLD lorsqu’elle a consulté les informations confidentielles des autres candidats, et qu’elle a été PDG du moment où HTLD a soumis sa candidature jusqu’au 23 mars 2016. (demande 16-11, § 8, p. 19, voir aussi réfutation, p. 3.) Les requérants prétendent que, en raison de son rôle au sein de HTLD, les informations qu’elle a obtenues « ont été fournies automatiquement à HTLD. » (Réfutation, p. 4.) Les requérants affirment en outre que « HTLD a reconnu que [Mme Ohlmer] a été (i) principalement chargée de représenter HTLD, (ii) très impliquée dans les processus d’organisation et de mobilisation des soutiens pour la candidature de [HTLD], et (iii) responsable du fonctionnement au jour le jour de l’entreprise. »31

            Le Conseil conclut que cet argument ne justifie pas un réexamen, car le Conseil a effectivement tenu compte de l’affiliation de Mme Olhmer avec HTLD lorsqu’il a adopté les résolutions 2016. En effet, les fondements des résolutions 2016.08.09.14 – à 2016.08.09.15 notent que : (1) Mme Ohlmer était une associée de M. Krischenowski ; (2) la société de Mme Ohlmer a acquis les actions que la société de M. Krischenowski possédait de GmbH Berlin, (étant elle même actionnaire minoritaire à 48,8 % d’HTLD) ; et (3) Mme Ohlmer (comme M. Krischenowski) a « certifié à l’ICANN [Org] que [elle] supprimerait ou détruirait toutes les informations obtenues, et a affirmé que [elle] n’avait pas utilisé et n’utiliserait pas les informations obtenues, ni ne les transmettrait à des tiers. » 32 Comme l’a souligné le BAMC dans sa recommandation, monsieur Grabensee a affirmé que GmbH Berlin transmettrait sa participation dans HTLD à une autre société, Afilias PLC. Une fois ce transfert ayant pris place, la compagnie de Mme Ohlmer n’aurait plus aucune participation dans HTLD.33

          4. Les arguments des requérants concernant les assurances de M. Krischenowski et HTLD et les relations de HTLD avec M. Krischenowski ne justifient pas un réexamen.

            Le Conseil conclut que l’argument des requérants que le Conseil n’aurait pas dû accepter les déclarations de M Krischenowski ou M, Grabensee indiquant que HTLD n’avait pas reçu les informations confidentielles de la configuration du portail ne justifie pas un réexamen parce que les requérants n’ont pas présenté d’arguments ou de faits qui n’avaient pas déjà été traités par le BAMC dans sa recommandation.

            De même, le Conseil conclut que les arguments des requérants que le conseil a omis de tenir compte du moment de la séparation de HTLD de M. Krischenowski lors de l’adoption des résolutions 2016 ne justifient pas un réexamen. Contrairement à l’argument des requérants, il est clair que le Conseil a examiné la question du moment de la séparation du HTLD avec M. Krischenowski lorsqu’il avait adopté les résolutions. Dans la justification des résolutions 2016, le Conseil a fait référence au même calendrier dans la justification pour les résolutions, notant que « les contrats de consultation entre M. Krischenowski et HTLD ont pris fin au 31 décembre 2015 » et « M. Krischenowski a démissionné de sa position de directeur général de GmbH Berlin en date du 18 mars 2016. »34 Les requérants sont en désaccord avec la conclusion du Conseil que le calendrier ne justifie pas de l’annulation de la candidature de HTLD, mais ce désaccord, sans plus d’argument, n’est pas un motif de réexamen.

          5. Les requérants ne contestent pas l’application de certains critères CPE spécifiques à la candidature de HTLD

            Les requérants indiquent que le BAMC a conclu à tort que les requérants « ne contestent pas l’application de critères CPE à la candidature de HTLD ou une conclusion particulière du fournisseur CPE sur l’un quelconque des critères CPE. » (Réfutation, p. 9, citant la recommandation, p. 1). Toutefois, ni la demande 16-11 ni la réfutation n’identifie l’un des critères de la CPE ni ne discute de l’application de certains critères CPE à la candidature de HTLD. (Voir demande 16-11 ; réfutation.) Les requérants ont tout simplement répété leurs arguments que le fournisseur CPE a appliqué des critères de CPE (non spécifiés) « de façon incohérente et erronée » et que le BAMC n’aurait pas dû prendre en considération les rapports de la révision du processus CPE lorsqu’il a présenté sa recommandation. (Réfutation, p. 9-10.) Le BAMC a répondu à ces arguments dans sa recommandation, et le Conseil d’administration adopte le raisonnement du BAMC comme il est parfaitement exposé dans le présent document.

            Pour ces raisons, le Conseil d’administration conclut que le réexamen n’est pas justifié.

            Cette action relève de la mission de l’ICANN et sert l’intérêt public dans la mesure où il est important de veiller à ce que, dans le cadre de sa mission et à l’égard de la communauté, l’ICANN mène ses activités dans le respect de l’acte constitutif, des statuts constitutifs et d’autres procédures établies, via un processus permettant à une personne ou entité substantiellement affectée par une action du Conseil d’administration ou du personnel de l’ICANN de demander le réexamen, par le Conseil d’administration, de cette action ou inaction. L’adoption de la recommandation du BGC n’a pas de répercussions financières sur l’ICANN et n’aura aucune incidence sur la sécurité, la stabilité et la résilience du système des noms de domaine.

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

    7. Considération de la demande de réexamen 18-9 : DotKids Foundation (.KIDS)

      Attendu que, dans sa résolution 2010.03.12.47, dans le cadre du programme des nouveaux gTLD, le Conseil d’administration de l’ICANN « a demandé aux parties prenantes de travailler avec leurs SO [organisations de soutiens] et AC [comités consultatifs] et de former un groupe de travail afin de développer une approche viable pour offrir un soutien aux candidats ayant besoin d’aide pour leurs candidatures et dans le fonctionnement des nouveaux gTLD.

      Attendu que, en réponse à la résolution 2010.03.12.47, le groupe de travail des SO/AC de soutien aux candidats de nouveaux gTLD (JAS WG) a été formé.

      Attendu que, le 13 septembre 2011, le JAS WG a publié son rapport final, énonçant diverses recommandations concernant le soutien financier et non financier pouvant être offert aux « candidats dont le soutien est approuvé » en conjonction avec le programme des nouveaux gTLD.

      Attendu que, dans la résolution 2011.10.28.21, le Conseil s’est engagé à prendre le rapport final du JAS au sérieux, et a convoqué un groupe de travail de membres du conseil « pour superviser le cadrage et la mise en œuvre des recommandations du rapport [final du JAS], autant que possible. »

      Alors que, dans les résolutions 2011.12.08.01 – à 2011.12.08.03, le Conseil a approuvé le plan de mise en œuvre du rapport final du JAS élaboré avec le groupe de travail du Conseil, demandant à l’organisation de finaliser le plan de mise en œuvre en conformité avec les critères proposés et de procéder au lancement du programme de soutien aux candidats (ASP) en janvier 2012, et a approuvé une réduction de frais de 47 000 USD pour les candidats pouvant bénéficier d’un soutien qui se qualifiaient selon les critères établis.

      Attendu que, le requérant a présenté une candidature communautaire pour .KIDS), qui a été placée dans un ensemble conflictuel avec une autre candidature .KIDS et une candidature pour .KID.

      Attendu que, le requérant a demandé et obtenu une aide financière sous la forme d’une réduction des frais de candidature conformément à l’ASP.

      Attendu que, le requérant avait participé à l’évaluation de la priorité communautaire et n’a pas gagné, et qu’une enchère de l’ICANN avait été prévue pour le 10 octobre 2018.

      Attendu que, en août 2018, le requérant a communiqué avec l’ICANN org afin de demander un soutien financier pour s’engager dans le processus de résolution de conflit de chaînes, soutien que l’ICANN org a refusé, car étant hors du champ d’application pour l’ASP.

      Attendu que, le 21 septembre 2018, le requérant a présenté une demande de réexamen 18-9, demandant de reconsidérer la réponse de l’ICANN org à sa demande d’aide financière pour participer au processus de résolution du conflit de chaînes.

      Attendu que, le Comité du Conseil d’administration chargé des mécanismes de responsabilité (BAMC) a précédemment déterminé que la demande 18-9 était suffisamment fondée et a envoyé la demande à l’ombudsman à des fins d’examen et de prise en compte conformément au chapitre 4 articles 4.2(j) et (k) des statuts constitutifs de l’ICANN.

      Attendu que, l’ombudsman s’est abstenu de prendre part aux discussions relatives à cette question conformément au chapitre 4 article 4.2(l)(iii) des statuts constitutifs.

      Attendu que, le BAMC a soigneusement pris en considération le bien-fondé de la demande 18-9 et tous les documents pertinents et a recommandé que la demande 18-9 soit rejetée, car l’organisation de l’ICANN a respecté les politiques et procédures établies dans sa réponse à la demande du requérant d’une aide financière pour participer au processus de résolution d’un conflit de chaînes ; et l’ICANN org n’a pas enfreint ses engagements établis dans les statuts constitutifs concernant l’intérêt public général.

      Attendu que, le 3 décembre 2018, le requérant a déposé une réfutation de la recommandation du BAMC concernant la demande 18-9.

      Attendu que, le Conseil a examiné attentivement la recommandation du BAMC concernant la demande 18-9 et tous les documents pertinents liés à la demande, dont la réfutation du requérant, et le Conseil accepte la recommandation du BAMC et conclut que la réfutation n’offre aucun argument ni élément de preuves à l’appui de sa demande de réexamen.

      Il est résolu (2019.01.27.24) que le Conseil d’administration adopte la recommandation du BAMC concernant la demande 18-9.

      Fondements de la résolution 2019.01.27.24

      1. Bref résumé et recommandation

        L’ensemble des faits est énoncé dans la recommandation du BAMC relative à la demande 18-9, (recommandation du BAMC) que le Conseil d’administration a examinée et prise en compte et qui est jointe aux présentes.

        Le 16 novembre 2018, le BAMC a évalué la demande 18-9 et tous les documents pertinents et a recommandé que le Conseil d’administration rejette la demande 18-9, car l’organisation de l’ICANN a respecté les politiques et procédures établies dans sa réponse au requérant concernant l’assistance financière pour s’engager dans le processus de résolution de conflit de chaîne ; et elle n’a pas enfreint ses engagements établis dans les statuts constitutifs concernant la transparence et l’ouverture.

        Le 3 décembre 2018, le requérant a déposé une réfutation de la recommandation du BAMC (réfutation). Le Conseil note que la réfutation a été présentée après le délai imparti en vertu du chapitre 4, article 4.2(q) des Statuts de l’ICANN. Néanmoins, le Conseil a examiné les arguments dans la réfutation du requérant et estime qu’ils ne justifient pas un réexamen pour les raisons énoncées ci-dessous.

      2. Problématique

        Les problématiques sont les suivantes :

        • Savoir si l’ICANN org a respecté les politiques établies en répondant à la demande du requérant de soutien financier pour s’engager dans le processus de résolution de conflit de chaîne pour l’ensemble conflictuel. KID/. KIDS selon l’ASP ; et
        • si l’ICANN org s’est conformée à ses valeurs fondamentales établies dans les statuts constitutifs concernant l’engagement de l’ICANN org envers l’intérêt public mondial.35

        Ces problématiques sont examinées sous les normes applicables aux demandes de réexamen énoncées dans la recommandation du BAMC.

      3. Analyse et fondements

        1. La réponse de l’organisation de l’ICANN à la demande du requérant d’une assistance financière a respecté les politiques et procédures établies.

          Les requérants indiquent qu’un réexamen est justifié parce que le refus de l’ICANN org de sa demande d’aide financière pour participer à la résolution conflictuelle contredit le rapport final du JAS. Plus précisément, le requérant soutient que l’ICANN org était sous des « conditions de temps » lorsqu’elle a examiné le rapport final du JAS, qui a fait que le Conseil d’administration de l’ICANN n’a approuvé la recommandation du JAS WG d’une réduction des frais de candidature pour les requérants qualifiés et, en conséquence, le Conseil de l’ICANN n’a « pas examiné » d’autres parties des recommandations à cette époque.36 Le BAMC a déterminé, et le Conseil a accepté que le requérant n’a fourni aucune preuve pour appuyer son affirmation selon laquelle le Conseil d’administration de l’ICANN n’a pas examiné l’ensemble du rapport final du JAS en 2011. Comme expliqué en détail dans la recommandation du BAMC et intégré par renvoi aux présentes, le Conseil d’administration de l’ICANN a pleinement pris en compte, de manière réfléchie, toutes les recommandations énoncées dans le rapport final du JAS. Le 28 octobre 2011, le Conseil de l’ICANN a décidé de « sérieusement » examiner le rapport final et a convoqué un groupe de travail de membres du Conseil « pour superviser le cadrage et la mise en œuvre des recommandations découlant du [rapport final du JAS], dans la mesure du possible ».37 Le Groupe de travail du Conseil a par la suite travaillé avec un sous-groupe de membres de la communauté nommés par le JAS WG pour développer les documents de processus et de critères qui énoncent la portée et les exigences de l’ASP, documents approuvés en décembre par le conseil en décembre 2011.38

          Le fait que le Conseil d’administration de l’ICANN n’aurait pas adopté toutes les recommandations du rapport final du JAS lorsqu’il a approuvé le plan de mise en œuvre en conformité avec les documents de processus et de critères n’appuie pas l’opinion du requérant disant que l’ICANN org n’a pas examiné (et rejeté) les recommandations qui n’ont pas été mises en œuvre. Le premier point est qu’aucune politique ou procédure n’exige de l’ICANN qu’elle adopte les recommandations définies dans le rapport final JAS dans leur totalité. Au contraire, comme on l’a noté dans le rapport final du JAS, les recommandations étaient seulement « soumises à l’examen de la GNSO, de l’ALAC, du Conseil d’administration de l’ICANN et la communauté de l’ICANN. »39 Le conseil d’administration de l’ICANN conserve le pouvoir discrétionnaire de déterminer laquelle des recommandations à mettre en œuvre, le cas échéant, et le Conseil de l’ICANN a décidé de le faire seulement « si possible. »40

          La position du requérant est également contredite par le langage clair des fondements des résolutions 2011.12.08.01 – à 2011.12.08.03, qui précisent que le conseil d’administration avait examiné et déterminé ne pas vouloir adopter toutes les recommandations énoncées dans le rapport final du JAS : « Remarque : Ce processus n’a pas suivi toutes les recommandations du JAS. »41 À la place, le Conseil, à sa discrétion, a estimé réalisable et résolu, d’approuver une aide financière sous la forme d’une « réduction des frais de 47 000 USD » pour chaque requérant éligible à ce soutien aux candidats.42

          Comme l’a souligné le BAMC, les seules recommandations du JAS approuvées par le Conseil sont celles définies dans les documents de processus et de critères, qui à leur tour définissent la portée et les exigences de l’ASP. Toutes les autres recommandations du JAS WG ont été étudiées et n’ont pas été adoptées. Parce que l’ASP, comme mis en œuvre, ne fournit pas d’assistance financière pour le processus de résolution conflictuelle, le Conseil accepte les conclusions du BAMC que l’ICANN org n’a contrevenu à aucune politique ou procédure déjà établie lorsqu’il a refusé la demande du requérant en vue d’un tel soutien.

          Le requérant n’identifie de plus aucune politique ou procédure (parce qu’il n’y en a aucune) obligeant l’ICANN à revenir en arrière et réexaminer, dans le cadre de la série du programme des nouveaux gTLD, les recommandations du JAS WG qui n’avaient pas été adoptées précédemment. Au contraire, les exigences de l’ASP telle qu’énoncées dans les documents de processus et de critères étaient destinées à être « des exigences très claires que sont les exigences finales du programme de soutien aux candidats. »43

          Le Conseil est également d’accord avec les conclusions du BAMC que même si le Conseil se devait de « traiter le reste du rapport final du JAS », comme le requérant le demande,44 le réexamen ne serait toujours pas justifié. Le BAMC a examiné le rapport final du JAS et les matériaux pertinents associés, y compris les observations faites en réponse à la demande de commentaires publics, et a confirmé que l’assistance financière sous la forme demandée par le requérant n’a jamais été recommandée par le JAS WG ou autrement. Ainsi, même si l’ICANN org devait « adopter le reste du rapport final du JAS », comme le requérant le demande,45 l’ICANN org ne trouverait pas de recommandation dans le rapport final du JAS indiquant qu’un soutien financier soit disponible pour s’engager dans le processus de résolution conflictuelle.

        2. L’ICANN Org a respecté ses valeurs fondamentales en répondant à la demande du requérant d’aide financière.

          Le Conseil est d’accord avec la conclusion du BAMC que l’ICANN org n’a pas violé ses valeurs fondamentales pour agir dans l’intérêt public mondial en refusant la demande de demande d’aide financière. Les valeurs fondamentales citées par le requérant précisent :

          rechercher et apporter son soutien à une participation élargie et informée qui reflète la diversité fonctionnelle, géographique et culturelle de l’Internet à tous les niveaux de l’élaboration de politiques et de la prise de décisions, afin de garantir que le processus d’élaboration de politiques ascendant et multipartite soit utilisé pour déterminer l’intérêt public mondial et que ce processus soit aussi responsable et transparent. 46

          La mise en œuvre de l’ASP de l’ICANN org est l’incarnation de ces valeurs fondamentales, et non pas, comme l’affirme le requérant, une transgression de celles-ci. La valeur de base de « rechercher et apporter son soutien à une participation élargie et informée » grâce au modèle multipartite est illustrée par la demande du conseil d’administration de l’ICANN, en mars 2010, que les parties prenantes « de travailler via leurs organisations de soutien et leurs comités consultatifs afin de former un groupe de travail visant à développer une approche durable pour fournir une assistance aux candidats qui en ont besoin pour faire acte de candidature pour les nouveaux gTLD et pour ensuite les exploiter. » 47 Le rapport final du JAS, que le Conseil d’administration de l’ICANN a pleinement pris en considération, a été élaboré en réponse à l’engagement de l’ICANN envers le modèle multipartite, et illustre bien l’engagement de l’ICANN de « s’assurer de l’intérêt public global » en ce qui concerne le programme des nouveaux gTLD. En décidant de considérer le rapport final du JAS, le Conseil d’administration note qu’il « considère sérieusement les déclarations de la communauté de l’ICANN selon lesquelles le soutien aux candidats encouragera la participation diversifiée au programme des nouveaux gTLD et promouvra l’objectif de l’ICANN visant à élargir le champ du modèle multipartite. »48

          Le BAMC a déterminé, et le Conseil a accepté que le requérant semble exhorter l’ICANN org à contourner la politique énoncée dans les exigences régissant l’ASP dans un sens favorable au requérant, ce qui mine, plutôt que soutenir, l’intérêt public mondial. L’ICANN org est résolue à assurer la diversité, la stabilité opérationnelle, et la non-discrimination, mais elle n’a pas la responsabilité de garantir un gTLD pour n’importe quel candidat spécifique. Le requérant n’a pas réussi à démontrer une violation quelconque des valeurs fondamentales de l’ICANN.

        3. La réfutation ne présente aucun argument ou fait justifiant le réexamen.

          Comme premier point, le Conseil note que la réfutation est hors délai. Le requérant a reçu la recommandation le 17 novembre 2018.49 La réfutation devait être présentée au plus tard dans les 15 jours suivants, c.-à-d. au plus tard le 2 décembre 2018.50 Le requérant a présenté sa réfutation le 3 décembre 2018, un jour après la date limite.51 Néanmoins, le Conseil a examiné les arguments dans la réfutation du requérant et estime qu’elles ne justifient pas un réexamen pour les raisons suivantes.

          1. La demande 18-9 cherche à obtenir le réexamen du refus de l’ICANN org de la demande du requérant de soutien financier.

            Le requérant fait valoir dans la réfutation, qu’il ne recherche pas « directement » une « aide financière ». (Réfutation, p. 1. Voir aussi id. p. 3 (La demande 18-9 « n’a demandé aucune forme particulière d’aide financière. »).) Toutefois, comme l’a souligné le BAMC dans la recommandation, le 27 août 2018, le requérant a envoyé un courriel à l’ICANN org déclarant qu’il était « à la recherche d’une demande de soutien financier pour s’engager dans le processus de résolution de conflit de chaînes. » (Recommandation du BAMC p. 9, citant l’annexe A de la recommandation). Le requérant a identifié la réponse de l’ICANN org à ce courriel « rejetant la demande » comme l’action qu’elle cherche à voir reconsidérée.52 Par conséquent, le BAMC a raisonnablement compris que la demande 18-9 était celle qui recherche le réexamen du déni par l’ICANN org de la demande du requérant d’un soutien financier.

            Le demandeur affirme maintenant que la demande 18-9 demande « simplement au Conseil d’administration de l’ICANN de lancer le processus d’examen des parties restantes du rapport final du JAS. » (Réfutation, p. 1.) Toutefois, le BAMC a déjà examiné cette réclamation. Le BAMC est arrivé à la conclusion que « l’ICANN org a sérieusement et pleinement tenu compte de toutes les recommandations énoncées dans le rapport final du JAS. » (Recommandation du BAMC, p. 13.) Le Conseil a accepté, et adopte le raisonnement énoncé dans la recommandation du BAMC.

            Le Conseil conclut que la réfutation du requérant n’a pas fourni de nouveaux arguments, ou identifié toute politique ou procédure (parce qu’il n’y en a aucune) obligeant l’ICANN à reconsidérer les recommandations du JAS WG qu’elle n’aurait pas adopté précédemment.

            Le Conseil note que la réfutation exprime son désaccord avec les conclusions du BAMC qu’il avait fait clairement savoir qu’il avait décidé de ne pas adopter toutes les recommandations énoncées dans le rapport final du JAS. Le requérant affirme que ceci « au mieux, laisse la question ouverte » quant à savoir si le Conseil devait accorder davantage d’attention aux recommandations qu’il n’a pas suivies. (réfutation, p. 2) Toutefois, rien dans les matériaux cités par le requérant ne prend en charge l’affirmation du requérant indiquant que le Conseil avait l’intention de « laisser[]. . .. ouvert » la possibilité de poursuivre l’examen des recommandations du JAS qu’il n’aurait pas adopté en 2011. (Réfutation, p. 2.) Comme le BAMC l’a expliquée, les résolutions 2011.12.08.01 – à 2011.12.08.03 et les documents à l’appui indiquent clairement que le Conseil d’administration avait examiné et décidé de ne pas adopter les recommandations du JAS WG, sauf celles définies dans les documents du processus et des critères. Plus précisément, la résolution 2011.12.08.01 enjoint l’ICANN org de « finaliser le plan de mise en œuvre en conformité avec les critères proposés et de procéder au lancement du programme de soutien aux candidats. »53 Les documents de processus et de critères ne fournissent pas le financement additionnel que le requérant cherche à obtenir ni ne permet une réévaluation potentielle des recommandations du JAS que le Conseil d’administration n’aurait pas adopté en 2011.54 Le Conseil n’est pas convaincu par les arguments du requérant du contraire, qui sont fondés sur des opinions. Celui-ci n’a pas fourni de nouveaux faits ou d’éléments de preuve pour démontrer qu’un réexamen était justifié.

          2. Le JAS WG n’a jamais recommandé un soutien financier sous la forme demandée par le requérant.

            Pour la première fois dans la réfutation, le requérant fait valoir que, sans « un soutien supplémentaire (p. ex., en termes de réduction, d’ajustement, d’étalement ou autre des frais), le programme de soutien au candidat n’a tout simplement pas de sens. » (Réfutation, p. 1.) À titre préliminaire, les statuts constitutifs stipulent que les réfutations « doivent. . .. être limitées à réfuter ou contredire les questions soulevées dans la » recommandation, et « ne doit pas offrir de nouveaux éléments de preuve » si le requérant « avait eu la possibilité de fournir » ces éléments de preuve lorsqu’il a initialement soumis la demande.55 Comme tel, cet argument ne réfute pas une question spécifique soulevée dans la recommandation ; il aurait dû être soulevée dans la demande, et n’aurait donc pas dû être soulevé dans la réfutation. En outre, toute remise en question faite auprès du Conseil d’administration des résolutions 2011.12.08.01 – à 2011.12.08.03 du conseil ou l’ASP est depuis longtemps frappée de forclusion. Néanmoins, le Conseil d’administration a examiné l’argument et conclut qu’il ne justifie pas un réexamen pour les raisons suivantes.

            Le requérant fait valoir que le BAMC conclut incorrectement qu’aucune des recommandations du JAS WG sur lesquels il se reposait dans la demande 19-9 « ne suggére une intention spécifique d’apporter une aide financière pour participer au processus de résolution de conflits. » (Réfutation, p. 3.) Le requérant affirme que « [m]ême si un soutien direct au processus de résolution de conflits n’est pas disponible, l’ajustement des autres frais pourrait avoir un impact important sur » les candidats dont le soutien est approuvé, et que le BAMC n’aurait pas dû avoir cette conclusion « simplement parce qu’une contribution directe ne pouvait pas être incluse[,]. . . d’autres rajustements des droits » auraient pu être envisagés. (Id.) La conclusion du BAMC n’était pas aussi limitée que le requérant le suggère ; le BAMC a conclu que le rapport final du JAS ne propose aucun type de soutien financier pour quelque portion du processus de résolution de conflit. (Recommandation du BAMC, p. 15-16.) En outre, comme l’a souligné le BAMC, le rapport final du JAS indiquait expressément que, dans le cas d’un conflit de chaînes, le candidat aurait à « financer cette étape supplémentaire » du processus. (Recommandation du BAMC, p. 16, citant le rapport final du JAS, 28.) Le requérant n’identifie aucune politique ou procédure (et il n’y en a aucune) exigeant de l’ICANN org de modifier ou d’ajouter aux recommandations du JAS WG pour fournir un appui supplémentaire au requérant ou d’autres candidats se trouvant dans la même situation lorsque le Conseil n’a pas pris de telles dispositions et que le rapport fait au conseil d’administration n’a même pas recommandé un tel soutien.

            Le Conseil conclut également que l’affirmation du requérant indiquant que la conclusion du BAMC que « tout autre soutien financier n’aidera pas » est inexacte. (Réfutation, p. 3.) Le BAMC est arrivé à la conclusion que l’ICANN org a respecté les politiques et procédures lorsqu’il a conclu qu’une aide financière supplémentaire au requérant n’était pas disponible en vertu de l’ASP. (Recommandation du BAMC, p. 12-16.)

            Pour les raisons ci-dessus, aucun des arguments de réfutation du requérant ne justifie un réexamen.

            Cette action relève de la mission de l’ICANN et sert l’intérêt public dans la mesure où il est important de veiller à ce que, dans le cadre de sa mission et à l’égard de la communauté, l’ICANN mène ses activités dans le respect de l’acte constitutif, des statuts constitutifs et d’autres procédures établies, via un processus permettant à une personne ou entité substantiellement affectée par une action du Conseil d’administration ou du personnel de l’ICANN de demander le réexamen, par le Conseil d’administration, de cette action ou inaction. L’adoption de la recommandation du BGC n’a pas de répercussions financières sur l’ICANN et n’aura aucune incidence sur la sécurité, la stabilité et la résilience du système des noms de domaine.

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

    8. Considération de la demande de réexamen 16-12 : Merck KGaA (.MERCK)

      Attendu que, Merck KGaA (le requérant) a présenté une candidature communautaire pour .MERCK (La candidature), qui a été placée dans un ensemble conflictuel avec d’autres candidatures .MERCK.

      Attendu que, le requérant a participé à l’évaluation de la priorité communautaire (CPE), mais n’a pas gagné.

      Attendu que, le requérant a présenté une demande de réexamen 16-12, demandant de reconsidérer le rapport de la CPE sur sa candidature, et l’acceptation par l’organisation de l’ICANN de ce rapport de la CPE.

      Attendu que, alors que la demande 16-12 était en cours, le Conseil d’administration a demandé à l’organisation de l’ICANN d’entreprendre une révision des processus CPE (révision du processus CPE). Le Comité de gouvernance du Conseil d’administration a déterminé que les demandes de réexamen en cours concernant le processus CPE, y compris la demande 16-12, seraient en attente jusqu’à la fin de la révision du processus CPE. 56

      Attendu que, le 13 décembre 2017, l’organisation ICANN a publié trois rapports sur la révision du processus CPE (les rapports sur la révision du processus CPE).

      Attendu que, le 15 mars 2018, le Conseil d’administration a voté les résolutions 2018.03.15.08 à 2018.03.15.11, dans lesquelles le Conseil d’administration a reconnu et accepté les conclusions des rapports sur la révision du processus CPE ; a déclaré que la révision du processus CPE était terminée ; a conclu que, sur la base des conclusions des rapports sur la révision du processus CPE, il n’y aurait aucune révision ou modification du processus CPE pour la série actuelle du programme des nouveaux gTLD ; et a enjoint au Comité du Conseil d’administration chargé des mécanismes de responsabilité (BAMC) de poursuivre l’examen du reste des demandes de réexamen relatives au processus CPE qui avaient été suspendues jusqu’à l’achèvement de la révision du processus CPE.

      Attendu que, conformément à la résolution 2018.03.15.08 à 2018.03.15.11, le BAMC a invité le requérant à soumettre des documents supplémentaires et à faire un exposé à l’appui de la demande 16-12.

      Attendu que, le requérant a présenté des documents à l’appui supplémentaires et fait une présentation téléphonique à l’appui de la demande 16-12 ; le requérant a également présenté un résumé écrit de sa présentation téléphonique au BAMC.

      Attendu que, le BAMC a soigneusement examiné le bien-fondé de la demande 16-12 et tous les documents pertinents, et a recommandé que demande 16-12 soit rejetée parce que le fournisseur CPE n’a pas enfreint de politiques ou procédures établies dans son évaluation du critère 2 et l’acceptation par l’ICANN org du rapport du fournisseur CPE était conforme aux politiques établies.

      Attendu que, le Conseil d’administration a soigneusement pris en considération la recommandation du BAMC concernant la demande 16-12 ainsi que tous les documents pertinents en lien et le Conseil d’administration est d’accord avec la recommandation du BAMC.

      Il est résolu (2019.01.27.25) que le Conseil d’administration adopte la recommandation du BAMC concernant la demande 16-12.

      Fondements de la résolution 2019.01.27.25

      1. Bref résumé et recommandation

        L’ensemble des faits est énoncé dans la recommandation du BAMC relative à la demande 16-12 (Recommandation du BAMC), que le Conseil d’administration a examinée et prise en compte et qui est jointe à ces présentes.

        Le 14 décembre 2018, le BAMC a évalué la demande 16-12 et tous les documents pertinents et a recommandé au Conseil d’administration de rejeter la demande 16-12, car le fournisseur CPE n’avait pas violé les politiques ou procédures établies dans son évaluation du Critère 2 et l’acceptation par l’organisation de l’ICANN du rapport du fournisseur CPE était conforme aux politiques établies.

        Le Conseil d’administration a soigneusement pris en considération la recommandation du BAMC ainsi que tous les documents pertinents en lien avec la demande 16-12 et le Conseil d’administration est d’accord avec la recommandation du BAMC.

      2. Problématique

        Les problématiques sont les suivantes :

        • Déterminer si le fournisseur CPE a respecté le guide pour appliquer le Critère 2, lien entre la chaîne proposée et la Communauté, dans le rapport de la CPE ;
        • si l’ICANN org a respecté les politiques et procédures applicables lorsqu’elle a accepté le rapport de la CPE ;
        • si l’ICANN org doit divulguer l’information documentaire et les communications entre l’ICANN org et le fournisseur CPE eu égard à la candidature ; et
        • si le Conseil a respecté les engagements, ses valeurs fondamentales et politiques lorsqu’il a reçu et accepté les résultats énoncés dans les rapports de révision du processus CPE.

        Ces questions sont examinées sous les normes applicables aux demandes de réexamen en vigueur au moment où cette demande 16-12 a été soumise. Ces normes sont abordées plus en détail dans la recommandation du BAMC.

      3. Analyse et fondements

        1. Critères et procédures CPE

          La CPE est un mécanisme de résolution de conflits disponible aux candidats qui enregistrent leur candidature comme des candidatures communautaires.57 Les normes et les processus CPE et sont définis dans le Module 4, Section 4.2 du Guide de candidature (guide). Les candidatures communautaires soumises à la CPE sont évaluées via les critères suivants : Critère 1 : Établissement de la communauté ; Critère 2 : Lien entre la chaîne proposée et la communauté ; Critère 3 : Politiques d’enregistrement ; et Critère 4 : Soutien communautaire.58 Conformément au guide, les critères sont présentés dans l’ordre dans lequel ils seront évalués par le fournisseur CPE. Pour réussir une CPE, une candidature doit recevoir au moins 14 des 16 points attribués par les quatre critères, chaque critère attribuant un maximum de quatre points. Une candidature qui réussit la CPE « élimine toutes les candidatures classiques en conflit direct avec celle-ci, indépendamment du degré d’admissibilité de ces dernières » .59 La CPE est effectuée par un panel indépendant composé de deux évaluateurs désignés par le fournisseur CPE.60 Le fournisseur CPE a pour rôle de déterminer si la candidature communautaire respecte les quatre critères de priorité communautaire indiqués au module 4.2.3 du guide.61

        2. Le fournisseur doit respecter les politiques et procédures dans son application du Critère 2.

          Le requérant affirme que le fournisseur CPE a commis une erreur en n’attribuant à la candidature aucun point sur les 4 possibles pour le critère 2. Le critère 2 évalue « la pertinence de la chaîne à la communauté spécifique qu’elle prétend représenter. »62 Il est mesuré par deux sous-critères : sous-critère 2-A-Lien (valeur maximale de trois points) ; et sous-critère 2-B-unicité (valeur maximale de un point).63

          1. Le fournisseur CPE a respecté les politiques et procédures dans son application du sous-critère 2-A-Lien.

            La candidature du requérant a reçu zéro point pour le sous-critère 2-A. Pour obtenir trois points pour le sous-critère 2-A, la chaîne candidate doit « correspondre au nom de la communauté ou être une abréviation ou forme courte bien connue de la communauté. »64 Le fournisseur a déterminé que la candidature du requérant ne satisfaisait pas au test des trois points parce que la chaîne demandée ne « correspondait pas au nom de la communauté, comme défini dans la candidature, et n’est pas non plus une forme courte bien connue ou une abréviation de la communauté. » 65

            Pour une note de deux, la chaîne candidate doit « décrire étroitement la communauté ou les membres de la communauté, sans pour autant toucher de nombreuses personnes au-delà de la communauté. » 66 Il n’est pas possible d’obtenir un score de 1 pour ce sous-critère. Le fournisseur CPE a également constaté que la candidature du requérant ne répond pas au test des deux points parce que la chaîne candidate n’« identifie pas… la communauté comme définie dans la candidature. » 67

            Le fournisseur CPE a conclu que

            bien que la chaîne « Merck » corresponde au nom de la communauté définie dans la candidature, elle correspond également au nom d’une autre entité commerciale connue comme « Merck » à l’intérieur des États-Unis et du Canada. Cette entreprise américaine, Merck & Co., Inc., travaille dans les secteurs pharmaceutiques, des vaccins et de la santé animale, a 68 000 employés et avait un revenu de 39,5 milliards USD en 2015. C’est donc une importante entité qui est également connue sous le nom « Merck » .68

            Le fournisseur a donc déterminé que la chaîne « touche substantiellement au-delà de la communauté... qu’elle définit, car la chaîne candidate identifie également une importante entité — Merck aux É-U et au Canada — qui ne fait pas partie de la communauté comme définie par le candidat » 69

            Le BAMC a constaté que, bien que le requérant soit en désaccord avec la conclusion du fournisseur CPE, celui-ci n’a identifié aucune politique ou procédure que le fournisseur CPE enfreignait dans sa détermination.70 Le demandeur n’a pas non plus apporté la preuve que le fournisseur CPE enfreignait une politique ou procédure déjà établie. Le BAMC a noté que le requérant ne conteste pas que l’entité basée aux États-Unis est connectée à la communauté du requérant, comme défini dans la candidature ; au contraire, la majorité de la demande 16-12 est consacrée à résumer les vieux différends juridiques entre le requérant et l’entreprise américaine Merck & Co., Inc. (une ancienne filiale du requérant) pour savoir laquelle peut utiliser le nom « Merck » à l’extérieur des États-Unis.71 En tant que tel, le BAMC a conclu, et le Conseil a accepté que le désaccord de fond du requérant avec la conclusion du fournisseur CPE n’est pas un motif de réexamen.

            En outre, comme signalé dans le rapport du second champ d’application de la révision du processus CPE, le fournisseur CPE a agi en cohérence avec le guide dans son analyse du sous-critère 2-A pour toutes les CPE qui ont été menées.72

            L’examen du traitement par le fournisseur CPE de la candidature Merck & Co. confirme la cohérence de l’analyse du fournisseur CPE du sous-critères 2-A pour l’ensemble du conseil pour toutes les CPE. Dans le rapport de la CPE sur la candidature communautaire déposée par Merck & Co., Inc. pour le gTLD .MERCK (rapport de CPE Merck & Co.), le fournisseur CPE a appliqué le même raisonnement à la candidature Merck & Co. que celui inclus dans le rapport de la CPE du requérant : il a constaté que la chaine candidate Merck & Co., Inc. (.MERCK) touche bien davantage de personne que la communauté parce que le requérant ici est « une importante entité connue aussi sous le nom de Merck » et n’est pas inclus dans la définition de la communauté de la candidature de Merck & Co. pour .MERCK.73 Ici, le fournisseur CPE a examiné la question de savoir si l’existence du requérant empêcherait la candidature Merck & Co. de recevoir les points sur l’élément de lien.74 C’est pour cette raison que le fournisseur CPE a attribué à la candidature Merck & Co. zéro point sur le sous-critère 2-A, tout comme le fournisseur l’a fait en ce qui concerne le requérant.75

            En ce qui concerne la réclamation du requérant concernant la taille de sa communauté qui serait plus importante que celle de la communauté associée avec Merck & Co., Inc. et, par conséquent, « la chaîne identifie clairement le requérant » 76, le BAMC a conclu, et le Conseil a accepté que cette affirmation ne fait pas apparaître que le fournisseur CPE n’a pas respecté une quelconque politique ou procédure déjà établie en concluant que la chaîne .MERCK touche bien au-delà de la définition communautaire de la candidature du requérant. Le requérant n’a pas non plus démontré que le fournisseur n’a pas respecté une quelconque politique ou procédure établie en accordant zéro point à l’élément de lien. Au contraire, comme l’a souligné le BAMC, le Guide indique que la note de zéro doit être accordée si la chaîne touche considérablement plus de gens que la communauté définie dans la candidature.

            Le BAMC a déterminé, et le Conseil a accepté que la suggestion du requérant qu’il aurait dû obtenir plus de points pour le sous-critère 2-A parce qu’il « allait prendre toutes les mesures nécessaires, y compris le ciblage géographique, afin d’éviter l’accès des utilisateurs à Internet dans les quelques territoires dans lesquels Merck & Co. possède les droits de marque » ne justifie pas le réexamen parce que le requérant n’indique point de politique ou procédure indiquant que le fournisseur CPE doit (ou même devrait) prendre en considération le ciblage géographique lors de l’évaluation du sous-critère 2-A. Le BAMC note que pareille politique n’existe pas dans le guide.

            En ce qui concerne la suggestion du requérant selon laquelle le fournisseur CPE a omis de considérer les preuves « d’intrusion illicite » dans ses territoires et les « usages illégaux » du mot Merck par Merck & Co., Inc.,77 le BAMC a conclu, et le Conseil a accepté que le fournisseur n'était pas tenu d'évaluer les longues années de conflit de marque entre le requérant et Merck & Co., Inc.78,79 En conséquence, le fournisseur n'a pas enfreint de politique ou de procédure établie en ne tenant pas compte des litiges en cours, et cet argument ne justifie pas le réexamen. Pour la même raison, le conseil est également d’accord avec la conclusion du BAMC que l’ICANN org n’était pas tenue d’offrir au fournisseur CPE des informations relatives à des contentieux entre le demandeur et Merck & Co., Inc. Le requérant ne fournit pas et ne peut pas identifier de politique ou procédure obligeant l’ICANN org à fournir de telles informations pour le fournisseur.

          2. L’application du sous-critère 2-A est compatible avec les autres rapports de la CPE.

            Le requérant affirme que l’analyse du fournisseur du sous-critère 2-A dans le rapport de la CPE est incompatible avec son analyse du même sous-critère pour les candidatures pour .ECO, .RADIO, .SPA, et .ART, prétextant que dans chacun de ces cas, le « requérant a obtenu trois points dans la partie LIEN même s’il y avait d’autres entités utilisant le même nom. » 80 Le BAMC a conclu, et le Conseil a accepté que le requérant ne fournit aucune preuve ou argument supplémentaire concernant cette affirmation et, en outre, l’argument est déplacé. Comme expliqué en détail dans la recommandation du BAMC et intégré par renvoi aux présentes, dans chacun de ces cas, le fournisseur CPE a déterminé que la chaîne candidate ne correspondait pas au nom de la communauté, mais elle identifiait la communauté sans pour autant toucher substantiellement à l’extérieur de la communauté.81 En revanche, le fournisseur CPE a conclu que .MERCK correspondait au nom de la communauté, mais il correspondait également au nom d’une autre communauté, celle, basée aux É.-U., de Merck & Co., Inc.82 En conséquence, le Conseil est d’accord avec les conclusions du BAMC qu’un réexamen sur cette base n’est pas justifié parce que le requérant n’a pas fourni la preuve que le fournisseur CPE avait agi en contradiction avec une politique ou procédure déjà établie.

          3. Le fournisseur CPE a respecté les politiques et procédures en appliquant le sous-critère 2-B-unicité.

            Le BAMC a déterminé, et le Conseil a accepté que le requérant n’a pas démontré que le fournisseur avait enfreint une quelconque politique ou procédure en ne donnant aucun point à la candidature du requérant pour le sous-critère 2-B-unicité. Pour obtenir 1 point pour le sous-critère 2-B, la chaîne candidate ne doit avoir aucune autre signification au-delà de la simple identification la communauté décrite dans la candidature.83 Une candidature qui ne peut pas bénéficier de deux ou trois points pour le sous-critère 2-A ne pourra obtenir un score de 1 pour le sous-critère 2-B.84 Ici, le fournisseur CPE n’a attribué aucun point en vertu du sous-critère 2-B, car la chaîne candidate n’a pas reçu une note de deux ou trois au sous-critère 2-A pour les raisons discutées ci-dessus.85

            Le requérant suggère que le fournisseur CPE aurait dû accorder à la candidature un point sur l’élément d’unicité parce que le requérant avait depuis longtemps l’usage exclusif de son nom communautaire MERCK.86 De même que ses arguments pour le sous-critère 2-A, le Conseil a accepté avec le BAMC que la contestation par le requérant de la notation de ce fournisseur CPE de ce sous-critère était basée uniquement sur un désaccord sur le fond avec les conclusions du fournisseur CPE, qui n’est pas un motif de réexamen. Le requérant n’a pas réussi à montrer une quelconque violation de politique ou procédure menant à la conclusion du fournisseur que la candidature ne devait recevoir aucun point pour le sous-critère 2-B.

        3. Le rapport CPE ne portait pas atteinte aux garanties de procédure régulière.

          Le requérant fait valoir que le fournisseur CPE « a omis de prendre un soin raisonnable » dans la rédaction du rapport de la CPE, « et a mal appliqué les normes et les politiques élaborées par l’ICANN dans le [guide], résultant pour le requérant en un déni des garanties d’une procédure régulière officielle. »87 Le Conseil est d’accord avec le BAMC que cet argument ne justifie pas le réexamen. Pour les raisons exposées ci-dessus et plus en détail dans la recommandation du BAMC, le requérant n’a pas prouvé l’existence d’un manquement par le fournisseur CPE dans le suivi de la politique et des procédures établies pour la CPE telles qu’énoncées dans le guide. Au contraire, le requérant suggère qu’il y aurait dû y avoir un processus officiel d’appel pour les décisions des fournisseurs tiers de l’ICANN, y compris le fournisseur CPE, les panels d’objection pour atteinte aux droits et les panels de confusion des chaînes. Les méthodes pour contester les déterminations dans le cadre de processus de résolution de conflits des gTLD sont définies dans le guide, qui a été élaboré après de vastes consultations auprès des communautés, et adopté par le Conseil en juin 2011.88 Le moment de contester le guide est révolu depuis longtemps.89

          Comme l’a souligné le BAMC, le guide offre une voie pour contester les résultats des processus de CPE par le biais des mécanismes de responsabilité de l’ICANN.90 En effet, le requérant a exercé ce droit par l’invocation de la procédure de réexamen avec la demande 16-12.91 En conséquence, le Conseil a conclu que, parce que l’application par le fournisseur CPE du critère 2 dans le cadre de la candidature était compatible avec le Guide, l’acceptation pour l’ICANN org du rapport de la CPE était également compatible avec les politiques et procédures applicables, et n’impliquait aucune violation de « procédure régulière ». Le Conseil a conclu également que l’absence dans le guide d’un mécanisme d’appel concernant le contenu des résultats d’évaluation ne constituait pas une violation de processus.

        4. La révision du processus de CPE confirme les résultats de la candidature Merck KGaA.

          Le rapport du champ d’application 2 de la révision du processus CPE montre que le fournisseur CPE a appliqué les critères CPE uniformément pour tous les CPE et qu’il n’y a aucune preuve que le processus d’évaluation de fournisseur ou ses rapports s’écartent des directives applicables.92 Pour cette raison supplémentaire, le BAMC a trouvé, et le Conseil a accepté que l’argument du requérant que le fournisseur a incorrectement appliqué le critère 2 ne justifiait pas un réexamen.

          Le requérant fait valoir que les rapports des champs d’application 2 et 3 de révision du processus CPE sont exagérément restreints et n’ont pas réévalué l’application par le fournisseur CPE du critère Lien ou évaluer le bien-fondé ou le caractère raisonnable de la recherche entreprise par le fournisseur CPE.93 Pour les raisons énoncées dans la recommandation et intégrées par renvoi aux présentes, le BAMC a conclu, et le Conseil a accepté que l’affirmation du requérant ne justifie pas un réexamen parce que le requérant n’a pas démontré de violation du processus ou de la procédure. (Recommandation du BAMC, pages 25-28.)

        5. La demande par le requérant de divulgation d’informations documentaires n’est pas un motif de réexamen.

          Le BAMC a déterminé, et le Conseil a accepté que la demande du requérant de divulgation d’informations documentaires entre l’ICANN org et le fournisseur CPE concernant la candidature et le rapport de la CPE n’a pas été correctement effectuée dans le contexte d’une demande de réexamen, car le requérant ne demande pas à l’ICANN org de reconsidérer l’action ou l’inaction du conseil ou du personnel.94 Cela étant, le Conseil convient avec le BAMC que ce n’est pas un motif de réexamen. Dans la mesure où le requérant désire faire une demande en vertu de la politique de divulgation d’informations documentaires (DIDP) de l’ICANN, il peut le faire séparément, conformément au DIDP.95 Toutefois, il convient de noter que l’information documentaire que le requérant demande a fait l’objet de multiples demandes DIDP et de demandes subséquentes de réexamen, un ensemble que le requérant peut envisager de consulter avant de présenter une demande supplémentaire en substance identique.96

          Pour les motifs précédents, le Conseil d’administration est arrivé à la conclusion que le réexamen n’était pas justifié.

          Cette action relève de la mission de l’ICANN et sert l’intérêt public dans la mesure où il est important de veiller à ce que, dans le cadre de sa mission et à l’égard de la communauté, l’ICANN mène ses activités dans le respect de l’acte constitutif, des statuts constitutifs et d’autres procédures établies, via un processus permettant à une personne ou entité substantiellement affectée par une action du Conseil d’administration ou du personnel de l’ICANN de demander le réexamen, par le Conseil d’administration, de cette action ou inaction. L’adoption de la recommandation du BGC n’a pas de répercussions financières sur l’ICANN et n’aura aucune incidence sur la sécurité, la stabilité et la résilience du système des noms de domaine.

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

    9. Divers


1 https://www.icann.org/en/system/files/correspondence/disspain-letter-review-new-gtld-cpe-process-26apr17-en.pdf.

2 Voir les statuts constitutifs de l’ICANN, 11 février 2016, chapitre 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

3 Lettre de M. Philipp Grabensee à l’ICANN (Https://www.icann.org/en/system/files/correspondence/grabensee-to-willett-23mar16-en.pdf. Les requérants font valoir que Mme Ohlmer a également été associée avec HTLD. Voir la demande 16-11, § 8, p.15. Le Conseil d’administration a considéré cette information en adoptant les résolutions 2016. Voir les fondements des résolutions 2016.08.09.14 – à 2016.08.09.15 (https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h. Le BAMC est arrivé à la conclusion que l’association de Mme Ohlmer avec HTLD, dont les requérants reconnaissent qu’elle a pris fin au plus tard le 17 juin 2016 (demande 16-11 § 8, p. 5) ne justifie pas un réexamen parce qu’il n’y a aucune preuve indiquant que des renseignements confidentiels auxquels Mme Ohlmer (ou M. Krischenowski) aurait pu accéder aient été fournis à HTLD ou ait créé un avantage indu pour la candidature de HTLD dans la CPE. Le Conseil d'administration est d'accord.

4 https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

5 Les documents d’information à l’appui des résolutions 2016.08.09.14 – 2016.08.09.15, p. 95-96 (https://www.icann.org/en/system/files/bm/briefing-materials-2-2-redacted-09aug16-en.pdf).

6 Id. p. 95-96.

7 Id., § 8, p. 9.

8 résolutions 2016 (Https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a).

9 Chapitre 4, § 2.5 des statuts constitutifs de l’ICANN, 11 février 2016.

10 Demande 16-11, § 8, p. 12.

11 Id. (emphase dans l’original).

12 Lettre de Crowell et Moring au Conseil d’administration de l’ICANN datée du 28 décembre 2016, p. 4-5 (Https://www.icann.org/en/system/files/files/reconsideration-16-11-trs-et-al-crowell-moring-to-board-redacted-28dec16-en.pdf

13 Id.

14 Demande 16-11, § 8, p. 12-13.

15 Résolutions 2018 (Https://www.icann.org/resources/board-material/resolutions-2018-03-15-en#2.a).

16 Rapport du 1er champ d’application de FTI, p. 3 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-1-communications-between-icann-cpe-provider-13dec17-en.pdf).

17 lettre de Petillion au BAMC du 1er février 2018, p. 3 (https://www.icann.org/en/system/files/files/reconsideration-16-11-trs-et-al-petillion-to-icann-bamc-redacted-01feb18-en.pdf.

18 Lettre de Petillion au BAMC en date du 1er février 2018, p. 3, citant le rapport du 1er champ d’application de FTI, p. 12 (soulignement ajouté).

19 Id.

20 Id., p. 3.

21 Rien dans les statuts de l’ICANN, la DIDP, ou une autre politique ou procédure n’exige de l’ICANN de volontairement produire dans le cadre d’un IRP des documents qui avaient été correctement retenus en réponse à une demande de DIDP.

22 Ordre de procédure No. 3, Dot Registry LLC v. ICANN, cas ICDR No. 01-14-0001-5004 (https://www.icann.org/resources/pages/dot-registry-v-icann-2014-09-25-en.

23 Les requérants étaient pleinement conscients que des communications se sont produites entre l’ICANN org et le panel CPE, puisque ces communications sont expressément envisagées dans le document du processus du panel CPE et l’ICANN a divulgué l’existence de ces communications dans la réponse à la demande du DIDP de 2014. Voir les documents du processus du panel CPE (https://newgtlds.icann.org/en/applicants/cpe [« l’unité d’intelligence économiste travaille avec l’ICANN lorsque des questions se posent ou lorsque d’autres processus d’information peuvent s’avérer nécessaires pour évaluer une candidature. »].

24 Demande 16-11, § 9, p. 20.

25 Rapport sur le champ d’application 2, p. 2 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf.

26 Recommandation du BAMC au sujet de la demande 18-6 (https://www.icann.org/en/system/files/files/reconsideration-18-6-trs-et-al-bamc-recommendation-14jun18-en.pdf.

27 Résolution 2918.07.18.09 (https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.g.

28 Voir les statuts constitutifs de l’ICANN, 11 février 2016, chapitre 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

29 Voir les statuts constitutifs de l’ICANN, 11 février 2016, chapitre 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

30 Voir Https://www.icann.org/resources/pages/reconsideration-16-11-trs-et-al-request-2016-08-25-en (fournissant des liens vers les lettres).

31 Id., citant la lettre de Grabensee à l’ICANN org datée du 18 mai 2016, (https://www.icann.org/en/system/files/correspondence/grabensee-to-willett-18may16-en.pdf).

32 Voir Fondements des résolutions 2016.08.09.14 – à 2016.08.09.15, Https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

33 Id.

34 Fondements des résolutions 2016.08.09.14 – à 2016.08.09.15, https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

35 Voir généralement, demande de réexamen 18-9.

36 Demande de réexamen 18-9, § 7 p, 4.

37 Résolution du Conseil d’administration du 28 octobre 2011 (Https://www.icann.org/resources/board-material/resolutions-2011-10-28-en#2.

38 Résolution du Conseil d’administration du 8 décembre 2011 (Https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1.

39 Rapport final du JAS I (soulignement ajouté) (Http://dakar42.icann.org/meetings/dakar2011/presentation-jas-final-report-13sep11-en.pdf).

40 Résolution du Conseil d’administration du 28 octobre 2011 (Https://www.icann.org/resources/board-material/resolutions-2011-10-28-en#2.

41 Résolution du Conseil d’administration du 8 décembre 2011(Https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1).

42 Résolution du Conseil d’administration du 8 décembre 2011 (Https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1.

43 Procès-verbaux du conseil du 28 octobre 2011 (soulignement ajouté) (Https://www.icann.org/resources/board-material/minutes-2011-10-28-en#2.

44 Demande de réexamen 18-9, § 7 p, 4.

45 Demande de réexamen 18-9, § 7 p, 4.

46 Chap. 1, § 1.2(b)(ii) des statuts constitutifs de l’ICANN Bylaws, 18 juin 2018.

47 Résolution du Conseil du 12 mars 2010 (Https://www.icann.org/resources/board-material/resolutions-2010-03-12-en.

48 https://www.icann.org/resources/board-material/minutes-2011-10-28-en#2.

49 Courriel du requérant à l’ICANN, datée du 3 décembre 2018, présenté comme pièce jointe __ pour les matériaux de référence.

50 Voir chap. 4. § 4,2(q) des statuts de l’ICANN, 18 juin 2018, (établissement d’une date limite pour la soumission des réfutations).

51 Voir https://www.icann.org/resources/pages/reconsideration-18-9-dotkids-request-2018-09-21-en.

52 Demande 18-9, § 2, p. 1.

53 Résolution 2018.12.08 .01 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1 [soulignement ajouté].)

54 Voir les documents de processus et de critères, inclus dans les documents d’information au Conseil pour la réunion du Conseil d’administration du 8 décembre 2011, aux pages 81 et 87 de 164 (Https://www.icann.org/en/system/files/bm/briefing-materials-3-08dec11-en.pdf.

55 chap. 4 § 4,2(q) des statuts constitutifs de l’ICANN, 22 juillet 2017.)

56 https://www.icann.org/en/system/files/correspondence/disspain-letter-review-new-gtld-cpe-process-26apr17-en.pdf.

57 Voir Guide, Module 4, § 4.2 p. 4 à 7 (Https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf. Voir également https://newgtlds.icann.org/en/applicants/cpe.

58 Id. au module 4, § 4.2, p. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

59 Id. au module 4, § 4.2.3, p. 4-9.

60 Id. au module 4, § 4.2.2.

61 Id. au module 4, §§ 4.2.2 et 4.2.3., p. 4-8 et 4-9 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

62 Voir Guide, Module 4, § 4.2.3 p. 4 à 13 (Https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf.

63 Id. p. 4-12 -4-13.

64 Id.

65 Rapport de la CPE, p. 3.

66 Id. p. 4 à 12.

67 Id.

68 Id.

69 Id.

70 Le requérant affirme que le BAMC devrait réévaluer la candidature dans l’élaboration d’une recommandation sur la demande 16-12. Voir la présentation écrite à l’appui de la présentation orale au BAMC du 4 septembre 2018, p. 1 (Https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-oral-presentation-bamc-20sep18-en.pdf). Les statuts en application de l’ICANN demandent au BAMC d’envisager seulement si l’action enfreint les politiques ou les procédures établies de l’ICANN et n’autorise pas le BAMC à effectuer un examen de novo de la candidature. Voir le chap. 4, §§ 2.1, 2,2 des statuts de l’ICANN, 11 février 2016.

71 Voir demande 16-12, § 8, P. 7-10.

72 rapport du champ d’application 2 de la révision du processus de CPE, p. 36-37 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf).

73 Id.

74 Rapport de la CPE sur Merck & Co., Inc., p. 4.

75 Id.

76 Demande, § 8, p. 9.

77 Id.

78 Voir demande 16-12, § 8, p. 7 à 10.

79 Voir, Guide, Module 4, § 4.2.3.

80 Résumé de la présentation 2017, p. 3 (Https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-summary-bgc-presentation-31mar17-en.pdf).

81 Rapport de la CPE sur .ART, p. 5 (https://newgtlds.icann.org/sites/default/files/tlds/art/art-cpe-1-1675-51302-en.pdf) ; Rapport de la CPE sur .SPA, p. 4 (https://newgtlds.icann.org/sites/default/files/tlds/spa/spa-cpe-1-1309-81322-en.pdf) ; Rapport de la CPE sur .ECO, p. 5-6 (https://newgtlds.icann.org/sites/default/files/tlds/eco/eco-cpe-1-912-59314-en.pdf) ; Rapport de la CPE sur .RADIO, p. 4-5 (https://newgtlds.icann.org/sites/default/files/tlds/radio/radio-cpe-1-1083-39123-en.pdf).

82 Rapport de la CPE. p. 3-4.

83 Id. p. 4 à 13.

84 Id. p. 4 à 14.

85 Rapport de la CPE, p. 5 ; voir aussi Guide, Module 4, § 4.2.3, p. 4 à 14 (« La formulation. . au-delà de l’identification de la communauté » pour l’obtention d’un point à titre d’« unicité » implique que la chaîne doit identifier la communauté, et par conséquent obtenir 2 ou 3 points pour la condition de « lien » afin de pouvoir gagner un point pour « unicité ».).

86 Demande, § 8, p. 11.

87 Demande 16-12, § 8, p. 6.

88 Id.

89 Voir Https://www.icann.org/resources/board-material/resolutions-2011-06-20-en#1. En vertu des statuts constitutifs en vigueur en juin 2012, les demandes de réexamen sont dues au plus tard trente jours après la publication de l’information au sujet de la décision du Conseil contestée ou dans les trente jours après qu’un requérant a eu connaissance ou aurait dû avoir connaissance de l’action du personnel contesté. Statuts constitutifs de l’ICANN, 16 mars 2012, chapitre IV, § 2.5 (https://www.icann.org/resources/pages/bylaws-2012-12-21-en#IV).

90 Guide, module 6, § 6, p. 6-4.

91 Le requérant a également exercé ce droit lorsqu’il a déposé une procédure IRP concernant des objections que celui-ci et Merck & Co., Inc. ont déposé l’un contre l’autre dans l’exercice de leurs candidatures concurrentes pour le gTLD .MERCK. Voir Https://www.icann.org/en/system/files/files/irp-merck-final-declaration-11dec15-en.pdf.

92 Rapport sur le champ d’application 2, p. 2 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf. Le requérant estime que le rapport du champ d’application 2 « n’a aucune incidence quant à la demande de réexamen de Merck KGaA ». (Lettre de Bettinger à l’ICANN datée du 12 avril 2018, p. 8.) Toutefois, les conclusions du rapport de champ d’application 2 sont directement pertinentes à la déclaration du requérant indiquant que la détermination du fournisseur CPE en ce qui concerne le sous-critère 2-A-Lien, était incompatible avec les déterminations de ce fournisseur CPE en vertu du même sous-critère pour .SPA .RADIO, .ART, et .ECO.

93 Lettre de Bettinger à l’ICANN du 12 avril 2018, p. 6 (Https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-supp-submission-12apr18-en.pdf). Voir également la présentation écrite à l’appui de la présentation orale de BAMC le 4 septembre 2018, p. 7 (Https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-oral-presentation-bamc-20sep18-en.pdf.

94 Lettre de Bettinger à l’ICANN du 12 avril 2018, p. 10.

95 Voir Https://www.icann.org/resources/pages/didp-2012-02-25-en.

96 Voir, p. ex., demande DIDP 20180115-1 et sa réponse (https://www.icann.org/resources/pages/didp-20180115-1-ali-request-2018-02-15-en) (Demande de réexamen rejetée le 18 juillet 2018 [https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.c]) ; demande DIDP 20180110-1 et sa réponse (https://www.icann.org/resources/pages/didp-20180110-1-ali-request-2018-02-12-en) (Demande de réexamen rejetée le 18 juillet 2018 [https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.b]).

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