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 de la réunion du Conseil d’administration
    2. Désignation au sein du Comité consultatif sur la sécurité et la stabilité
    3. Désignation au sein du Comité consultatif du système des serveurs racine
    4. Renouvellement du bail du bureau de Singapour
    5. Renouvellement du bail du bureau de Bruxelles
    6. Rapport consultatif du SSAC sur la protection des titulaires de nom de domaine liée au cycle de vie de la gestion des informations d’identification
    7. Renouvellement du contrat de registre .MUSEUM
  2. Ordre du jour principal :
    1. Confirmation de l’objectif du fonds de réserve
    2. Adoption du plan opérationnel et du budget IANA pour l’exercice fiscal 2019 (EF19)
    3. Traitement des candidatures de .CORP, .HOME et .MAIL dans le cadre du programme des nouveaux gTLD
    4. Avis du GAC : Communiqué d’Abu Dhabi (novembre 2017)
    5. Prochaines étapes dans la révision du processus d’évaluation de la priorité communautaire — MISE À JOUR UNIQUEMENT
    6. Divers

 

  1. Ordre du jour approuvé :

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

      Il est résolu (2018.02.03.01), que le Conseil d’administration approuve le procès-verbal de la réunion du Conseil d’administration de l’ICANN du 13 décembre 2017.

    2. Désignation au sein du Comité consultatif sur la sécurité et la stabilité

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

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

      Il est résolu (2018.02.08.02), que le Conseil d’administration nomme Barry Leiba et Chris Roosenraad au SSAC pour un mandat devenant effectif immédiatement après son approbation par le Conseil d’administration et prenant fin le 31 décembre 2020.

      Fondements de la résolution 2018.02.04.02

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

      Le fonctionnement continu du SSAC en tant qu’organe compétent dépend de l’ensemble des experts dans des domaines donnés qui consentent à consacrer une partie de leur temps et de leur énergie pour mener à bien la mission du SSAC.

      De nombreux membres du SSAC connaissent Barry Leiba par son travail important dans le groupe de travail de génie Internet (IETF), notamment en tant que président du groupe de travail, administrateur du domaine des candidatures, et au sein du conseil d’architecture de l’Internet. Il apporte une expertise considérable dans les normes en matière de messagerie Internet et celles liées à la messagerie, de façon plus générale les protocoles de couches d’application et les aspects liés à leur sécurité et confidentialité. Il possède un solide bagage dans les problèmes d’internationalisation.

      Chris Roosenraad a participé activement au Groupe de travail anti-abus pour la messagerie (MAAWG). Il a participé à la coalition pour la technologie et conseillé le gouvernement américain par l’entremise du processus du conseil de la Commission fédérale des communications des États-Unis sur la sécurité, la fiabilité et l’interopérabilité (CSRIC). Il possède une vaste expérience de la gestion de certains des plus grands services d’infrastructure Internet, y compris les DNS, DHCP, e-mail, et la gestion de l’identité.

      Le SSAC est persuadé que Barry Leiba et Chris Roosenraad seront des membres actifs importants en son sein.

      La nomination de membres du SSAC ne devrait pas avoir d’impact financier sur l’organisation de l’ICANN qui n’ait déjà été intégré aux ressources budgétaires nécessaires pour un soutien continu du SSAC.

      Cette décision est conforme à l’intérêt public et à la mission de l’ICANN, avec l’exercice d’une responsabilité spécifiquement réservée au conseil d’administration au sein des statuts constitutifs, et elle soutient les travaux communautaires sur la sécurité et les questions liées à la stabilité.

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

    3. Désignation au sein du Comité consultatif du système des serveurs racine

      Attendu que, le chapitre 12 article 12,2 (c) (ii) des statuts constitutifs mentionne que le Conseil d’administration doit nommer les co-présidents et les membres du comité consultatif du système des serveurs racine (RSSAC).

      Attendu que, le 5 décembre 2017, le RSSAC a procédé à une élection pour un poste de co-président et a réélu Brad Verd de Verisign (organisation des opérateurs de serveur racine A/J) pour un mandat final de deux ans en tant que co-président.

      Attendu que, le RSSAC demande au Conseil d’administration d’agir en nommant son co-président.

      Il est résolu (2018.02.04.03) que, le Conseil d’administration accepte la recommandation du RSSAC et nomme Brad Verd pour un mandat de 2 ans en tant que co-président du RSSAC et lui souhaite beaucoup de succès dans ce rôle important.

      Fondements de la résolution 2018.02.04.03

      Les statuts constitutifs de l’ICANN demande au Conseil d’administration nomme les co-présidents du RSSAC comme choisis par les membres du RSSAC. La nomination de ces co-présidents permettra au RSSAC d’être correctement composé afin de remplir sa fonction de comité consultatif.

      La nomination des présidents du RSSAC ne devrait pas avoir d’impact financier sur l’organisation de l’ICANN qui n’ait déjà été intégré aux ressources budgétaires nécessaires pour un soutien continu du RSSAC.

      Cette décision est conforme à l’intérêt public et à la mission de l’ICANN, par l’exercice d’une responsabilité spécifiquement réservée au Conseil d’administration dans les statuts constitutifs, et elle soutient le travail de la communauté sur les des questions opérationnelles du serveur racine.

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

    4. Renouvellement du bail du bureau de Singapour

      Attendu que, l’ICANN conserve un bureau régional à Singapour depuis 2013.

      Attendu que, le bail en cours de l’espace du bureau régional de l’ICANN à Singapour expire en 2018.

      Attendu que, l’organisation de l’ICANN a évalué les options de renouveler le bail existant, ou de passer à un autre endroit adapté.

      Attendu que, l’ICANN org a recommandé au Conseil d’administration qu’il autorise le Président-directeur général ou son ou ses représentants désignés à prendre toutes les mesures nécessaires pour renouveler le bail de l’espace actuel de Singapour, tel que reflété dans les documents de référence de cet article, et à faire tous les déboursements nécessaires en vertu de ce bail.

      Attendu que, lors de sa réunion du 24 janvier 2018, le Comité des finances du Conseil (BFC) a examiné les incidences financières des options évaluées pour le Bureau régional de l’ICANN à Singapour.

      Attendu que, la BFC a déterminé que la proposition de reconduction du bail de l’actuel bureau régional de Singapour était raisonnable et correctement reflétée dans le plan opérationnel et budget EF19.

      Il est résolu (2018.02.04.04), que le Conseil autorise le Président-directeur général ou son ou ses représentants désignés à prendre toutes les mesures nécessaires pour renouveler le bail de l’espace du bureau de Singapour, tel que reflété dans les documents de référence de cet article, et à faire tous les déboursements nécessaires en vertu de ce bail.

      Fondements de la résolution 2018.02.04.04

      Pour soutenir sa stratégie de mondialisation, l’ICANN a établi un bureau régional à Singapour afin de mieux desservir ses parties prenantes. Pour illustrer l’engagement de l’ICANN à sa stratégie de mondialisation, et répondre à la demande croissante d’espace pour accueillir la croissance projetée de l’organisation de l’ICANN à Singapour, un bail de trois ans commençant en octobre 2015 a été signé avec South Beach Tower. Le bureau régional de Singapour a été déplacé d’un bureau équipé à une installation plus permanente. Le bail actuel expire le 30 septembre 2018, et l’ICANN org et le comité de finances du Conseil d’administration (BFC) ont proposé que le bail soit renouvelé pour une nouvelle période de trois ans.

      L’ICANN org a mené un examen du marché et effectué une analyse des coûts de renouvellement du bail par rapport à un déménagement, et a constaté que le renouvellement du bail était plus viable et rentable.

      Le Conseil a examiné les recommandations de l’ICANN org et de son comité des finances de renouveler le bail actuel pour une période supplémentaire de trois ans et l’estimation faite que la proposition satisfait aux exigences financières et commerciales de l’organisation.

      Prendre cette décision est à la fois compatible avec la mission de l’ICANN et dans l’intérêt public, car avoir un bureau régional dans la région de l’Asie-Pacifique permet de desservir les parties prenantes de l’ICANN d’une façon plus efficace et efficiente.

      Renouveler le bail actuel pour une durée supplémentaire de trois ans aura un impact financier sur l’ICANN. Cet impact est actuellement inclus dans le plan opérationnel et budget EF19 qui attend l’approbation du Conseil d’administration.

      Cette décision n’aura aucun impact direct sur la sécurité stabilité ou la résilience du système des noms de domaine.

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

    5. Renouvellement du bail du bureau de Bruxelles

      Attendu que, l’ICANN a maintenu un bureau régional à Bruxelles, pour plus d’une décennie.

      Attendu que, le bail au bureau régional de Bruxelles actuel expire en 2021.

      Attendu que, l’organisation de l’ICANN a évalué les options de négocier un taux réduit pour le bail existant sous réserve d’un engagement de trois années supplémentaires, ou de déménager dans un autre endroit adapté.

      Attendu que, le comité de finances du Conseil d’administration a recommandé au Conseil d’administration qu’il autorise le Président-directeur général ou son ou ses représentants désignés à prendre toutes les mesures nécessaires pour conclure la révision du bail pour l’actuel espace de bureau à Bruxelles, telle que reflétée dans les documents de référence, et à faire tous les déboursements nécessaires en vertu de ce bail.

      Attendu que, lors de sa réunion du 24 janvier 2018, le Comité des finances du Conseil d’administration (BFC) a examiné les incidences financières des options évaluées concernant le bureau régional de l’ICANN à Bruxelles.

      Attendu que, la BFC a déterminé que la proposition de la mise à jour du bail du bureau régional de Bruxelles existant était raisonnable et correctement reflétée dans la version préliminaire du plan opérationnel et budget EF19.

      Il est résolu (2018.02.23.10) que le Conseil autorise le Président-directeur général ou son ou ses représentants désignés à prendre toutes les mesures nécessaires pour conclure la révision du bail de l’actuel espace de bureau de Bruxelles, telle que reflétée dans les documents de référence, et à faire tous les déboursements nécessaires en vertu de cette révision.

      Il est résolu (2018.02.04.06) 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) et 3.5 (d) 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 2018.02.04.05 à 2018.02.04.06

      Pour soutenir sa stratégie de mondialisation, l’ICANN a établi un bureau à Bruxelles au début de son histoire afin de mieux desservir ses parties prenantes. Pour illustrer l’engagement de l’ICANN dans sa stratégie de mondialisation, et répondre à la demande croissante de desserte des parties prenantes européennes par l’entremise du bureau régional de Bruxelles, l’organisation de l’ICANN s’est engagée à évaluer le rapport coût-efficacité du bail actuel du bureau de Bruxelles. L’ICANN org a mené un examen du marché et une analyse de la mise à jour du bail actuel par rapport à un déménagement, et a constaté que le renouvellement du bail était plus viable et rentable.

      En novembre 2017, l’ICANN org a évoqué une option de résiliation anticipée du bail du bureau régional de Bruxelles, qui a conduit à une discussion avec le propriétaire sur le bail actuel. Le bailleur a finalement proposé de réduire les loyers de paiement annuels de [ÉLÉMENT SUPPRIMÉ AUX FINS DE NÉGOCIATION] à des paiements de [ÉLÉMENT SUPPRIMÉ AUX FINS DE NÉGOCIATION], sous réserve d’une révision du bail avec option de résiliation anticipée dans six ans (2024) et une date finale en 2027.

      Au total, une fois que l’impôt foncier et d’autres frais sont inclus, l’engagement annuel (incitations comprises) s’élèverait à [ÉLÉMENT SUPPRIMÉ AUX FINS DE NÉGOCIATION] par rapport à l’arrangement actuel de [ÉLÉMENT SUPPRIMÉ AUX FINS DE NÉGOCIATION] d’où une économie globale d’un peu plus de 12 %.

      En outre, le bailleur a promis une contribution de [ÉLÉMENT SUPPRIMÉ AUX FINS DE NÉGOCIATION] pour les coûts potentiels de rénovation du bureau, ce qui permettra à l’ICANN org d’envisager des améliorations fonctionnelles, telles que la création d’un plus grand espace de réunion, convenant mieux pour héberger des ateliers de l’ICANN, ou des groupes de travail sur les politiques, par exemple.

      Le Conseil a examiné les recommandations de l’ICANN org et de son comité des finances de renouveler le bail actuel pour une période supplémentaire de trois ans au prix réduit offert par le bailleur et l’estimation faite que la proposition satisfait aux exigences financières et commerciales de l’organisation.

      Prendre cette décision est à la fois compatible avec la mission de l’ICANN et dans l’intérêt public, car avoir un bureau régional dans la région de Bruxelles permet de desservir les parties prenantes de l’ICANN d’une façon plus efficace et efficiente.

      Renouveler le bail actuel pour une durée supplémentaire de trois ans aura un impact financier sur l’ICANN. Cet impact est actuellement inclus dans le plan opérationnel et budget EF19 qui attend l’approbation du Conseil d’administration.

      Cette décision n’aura aucun impact direct sur la sécurité stabilité ou la résilience du système des noms de domaine.

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

    6. Rapport consultatif du SSAC sur la protection des titulaires de nom de domaine liée au cycle de vie de la gestion des informations d’identification

      Attendu que, le Comité consultatif sur la sécurité et la stabilité (SSAC) a présenté quatre recommandations dans les documents SAC : SAC074, recommandation du SSAC sur la protection des titulaires de noms de domaine : meilleures pratiques pour préserver la sécurité et la stabilité dans le cycle de gestion des informations d’identification.

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

      Attendu que, le Conseil d’administration a examiné l’avis du SSAC et les recommandations de mise en œuvre de l’ICANN org concernant cette proposition.

      Il est résolu (2018.02.04.07) que le Conseil d’administration adopte la fiche de suivi intitulée « Mise en œuvre des recommandations pour le document d’avis du SSAC SAC074 » [PDF, 49 Ko], et demande au Président-directeur général, ou son ou ses représentants, de mettre en œuvre l’avis comme décrit dans la fiche de suivi.

      Fondements de la résolution 2018.02.04.07

      Le registre de demandes d’intervention est un cadre visant à améliorer le processus par lequel le Conseil d’administration analyse les recommandations qui lui sont adressées, y compris l’avis de ses comités consultatifs. L’élaboration de ce cadre date de 2015 et, dans le cadre de son effort initial, l’organisation ICANN a examiné les avis du SSAC émis entre 2010 et 2015 pour identifier les éléments qui n’avaient pas encore été considérés par le Conseil d’administration.

      Les résultats de cette révision initiale ont été communiqués au président du SSAC dans une lettre du président du Conseil d’administration de l’ICANN, en date du 19 octobre 2016 (voir https://www.icann.org/en/system/files/correspondence/crocker-to-faltstrom-19oct16-en.pdf [PDF, 627 Ko]). Cette demande a été identifiée comme faisant partie de l’évaluation de l’inventaire des avis en suspens réalisé en 2016 pour lancer le registre de demandes d’intervention. Cette résolution est destinée à répondre à l’un des avis du SSAC qui ont été identifiés comme en suspens à ce moment-là.

      Dans le cadre du processus du registre de demandes d’intervention, pour chaque élément de l’avis présenté dans le cadre de cette résolution, l’ICANN org a examiné la demande, a confirmé au SSAC avoir compris la demande et évalué la faisabilité de la demande. Dans le cadre de son évaluation de la faisabilité de mettre en œuvre les avis, l’ICANN org a considéré qu’ils pourraient être mis en œuvre dans le cadre de la demande de l’actuel budget opérationnel EF19, et ceci est indiqué dans chaque recommandation sur la fiche de suivi.

      En prenant ces mesures, le Conseil a considéré les recommandations de l’ICANN org reflétées dans la fiche de suivi [PDF, 49 Ko].

      Cette décision est conforme à l’intérêt public et à la mission de l’ICANN, dans la mesure où celle-ci consiste spécifiquement à maintenir l’opération sécuritaire et stable du DNS d’Internet, et à défendre également les structures permettant l’apport consultatif spécifié dans les statuts constitutifs de l’ICANN.

      La mise en œuvre de l’avis du SSAC soutient la sécurité ou la stabilité du système des noms de domaine.

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

    7. Renouvellement du contrat de registre .MUSEUM

      Attendu que, l’ICANN a commencé une période de commentaires publics du 24 août 2017 au 3 octobre 2017 sur la proposition de renouvellement du contrat pour le domaine de premier niveau (TLD) .MUSEUM, recevant des commentaires de quatre organisations ainsi qu’une réponse de l’opérateur de registre .MUSEUM. Un résumé et une analyse des commentaires ont été fournis au Conseil d’administration.

      Attendu que, le contrat de renouvellement de registre de .MUSEUM inclut de nouvelles dispositions conformes aux dispositions comparables du contrat de registre des nouveaux gTLD.

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

      Il est résolu (2018.02.04.08), que le contrat de renouvellement du registre de .MUSEUM proposé est approuvé, et le président-directeur général, ou son représentant, est autorisé à prendre les mesures qui s’imposent pour conclure et mettre en œuvre ledit contrat.

      Fondements de la résolution 2018.02.04.08

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

      L’ICANN et MuseDoma ont conclu un contrat de registre le 1er juillet 2001 pour l’exploitation du domaine de premier niveau (TLD) .MUSEUM. Le contrat de registre de .MUSEUM en vigueur expire le 2 mars 2018. Le contrat de renouvellement de registre proposé a été publié pour commentaires publics entre le 24 août 2017 et le 3 octobre 2017. À l’heure actuelle, le Conseil d’administration approuve le contrat de renouvellement de registre proposé pour la poursuite de l’exploitation du TLD .MUSEUM par MuseDoma.

      Quelle est la proposition à l’étude ?

      Le projet de renouvellement du contrat de registre .MUSEUM, approuvé par le Conseil d’administration, est basé sur l’actuel contrat de registre .MUSEUM avec des modifications convenues par l’ICANN et par MuseDoma ; il comprend certaines dispositions d’un contrat de registre de base des nouveaux gTLD.

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

      Du 24 avril 2017 au 3 octobre 2017, l’organisation de l’ICANN a mené une période de consultation publique sur le thème de la proposition de contrat de renouvellement de registre de .MUSEUM. En outre, l’ICANN a lancé des négociations bilatérales avec l’opérateur de registre pour convenir de l’ensemble des termes à inclure dans la proposition de contrat de renouvellement de registre publié pour consultation publique.

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

      Le forum de commentaire public sur la proposition de contrat de renouvellement de registre de .MUSEUM s’est achevé le 4 octobre 2017, l’organisation ICANN ayant reçu cinq (5) commentaires. Les commentaires peuvent se résumer dans les trois principales catégories énumérées ci-dessous.

      1. Inclusion des mécanismes de protection des droits et des sauvegardes des nouveaux gTLD dans les gTLD historiques : Deux intervenants ont appuyé l’inclusion de certains mécanismes de protection des droits, comme le système uniforme de suspension rapide (URS), la procédure de règlement de litiges après délégation relatifs à des marques déposées et les engagements d’intérêt public (PIC) (c.-à-d. les sauvegardes) contenus dans le contrat de registre des nouveaux gTLD comme l’exigence d’utiliser des bureaux d’enregistrement ayant signé le contrat d’accréditation de bureau d’enregistrement (RAA) de 2013. Inversement, deux commentateurs ont manifesté leur préoccupation quant à l’inclusion des mécanismes de protection de droits des nouveaux gTLD dans le cadre des contrats historiques. Ils ont affirmé que ces dispositions ne devaient pas être ajoutées à la suite de négociations de contrat, mais qu’elles devraient plutôt être abordées à travers le processus d’élaboration de politiques (« PDP »). En outre, la recommandation est pour le Conseil de « déclarer un moratoire sur l’imposition des RPM des nouveaux gTLD jusqu’à ce que le PDP référencé ci-dessus soit conclu ; le Conseil de la GNSO a donné suite à ces recommandations, et toutes les questions de mise en œuvre et de transition ont été abordées ».
      2. La transition de .MUSEUM d’un TLD « sponsorisé » en un TLD « communautaire » : Deux intervenants ont exprimé leur préoccupation concernant la mise à jour des conditions d’admissibilité pour .MUSEUM comme décrites dans la spécification 12 par rapport aux exigences faites aux candidats à un nouveau gTLD « communautaire » et devant être incorporées dans leurs politiques d’enregistrement. Pour ces commentateurs, il existe une possibilité de manque de cohérence en ce qui concerne le concept de TLD « communautaire » et la façon dont il est appliqué.
      3. Le processus de négociation pour le renouvellement du contrat de registre proposé pour .MUSEUM et les négociations des contrats de registre des gTLD historiques en général : Deux commentateurs ont demandé si le processus de négociation visant à renouveler et modifier les contrats de registre historiques était suffisamment transparent et la façon dont le contrat de renouvellement avait été mis au point.

      En réponse aux commentaires exprimés à propos de la transition de .MUSEUM d’un TLD « sponsorisé » à un TLD « communautaire » MuseDoma, l’opérateur de registre pour .MUSEUM, a fourni par écrit une réponse, indiquant que l’opérateur de registre mettra en œuvre des « mécanismes de mise en œuvre à respecter » dans ses politiques d’enregistrement. En outre, MuseDoma a expliqué dans sa réponse :

      « le registre procédera à une post-validation sur la base de critères d’admissibilité, par le biais d’un processus de validation aléatoire ciblé ou à la demande d’un tiers. La validation comprendra des vérifications sur l’utilisation réelle du nom de domaine enregistré. Une documentation ou preuve sera requise de la part du titulaire de nom de domaine ; l’admissibilité sera souvent plus facilement démontrée par l’adhésion à l’ICOM ou autre association professionnelle des musées.

      L’objectif des mécanismes d’application de la loi est de protéger la crédibilité du TLD .MUSEUM pour son public dans le monde entier. En particulier, faire respecter l’objectif communautaire du TLD .MUSEUM et aider à prévenir l’utilisation abusive ou les comportements malveillants. »

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

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

      • la proposition de contrat de renouvellement de registre du TLD .MUSEUM
      • la version annotée montrant les modifications proposées au contrat de registre de .MUSEUM en vigueur
      • le contrat de registre actuel de .MUSEUM
      • le contrat des nouveaux gTLD — 31 juillet 2017
      • les résumé et analyse des commentaires publics

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

      Le Conseil d’administration a soigneusement examiné les commentaires publics reçus au sujet du contrat de renouvellement de registre de .MUSEUM, ainsi que le résumé et l’analyse de ces commentaires. Le Conseil d’administration a également examiné les termes convenus par l’opérateur de registre dans le cadre des négociations bilatérales avec l’organisation de l’ICANN.

      Bien que le Conseil reconnaisse les préoccupations exprimées par certains membres de la communauté concernant l’inscription de l’URS dans le contrat de renouvellement de registre, le Conseil note que cette inclusion dépend des négociations bilatérales entre l’ICANN et l’opérateur de registre, lorsque l’opérateur de registre a manifesté son intérêt de renouveler son contrat de registre pour se conformer aux dispositions du contrat de registre des nouveaux gTLD.

      Le Conseil d’administration note que l’URS a été recommandé par l’équipe chargée de l’élaboration de recommandations pour la mise en œuvre (IRT) comme un mécanisme de protection des droits (RPM) obligatoire pour tous les nouveaux gTLD. Il a été demandé à la GNSO de donner son point de vue concernant les mécanismes de protection des droits recommandés (qui comprenaient l’URS) et leur cohérence avec la politique d’introduction des nouveaux gTLD proposée par la GNSO et s’ils constituaient une option appropriée et effective pour atteindre les principes et les objectifs fixés par la GNSO. L’équipe de révision des problèmes spécifiques aux marques commerciales (STI) a examiné cette question et a conclu que « l’utilisation de l’URS doit être un RPM requis pour tous les nouveaux gTLD ». Autrement dit, la GNSO a déclaré que l’URS n’était incompatible avec aucune de ses recommandations de politique existantes.

      Bien que l’URS ait été développé et peaufiné par le processus décrit ici, y compris une révision publique et une discussion au sein de la GNSO, il n’a pas été adopté comme une politique consensuelle et l’ICANN n’a aucune possibilité de le rendre obligatoire pour des TLD autres que les candidats aux nouveaux gTLD ayant déposé leur candidature au cours de la série de nouveaux gTLD de 2012.

      Par conséquent, l’approbation du contrat de renouvellement de registre par le Conseil d’administration n’est pas une motion pour rendre l’URS obligatoire pour les TLD historiques, et il serait inapproprié de le faire. Dans le cas de .MUSEUM, l’inclusion de l’URS a été développée dans le cadre de la proposition au cours des négociations bilatérales entre l’opérateur de registre et l’ICANN.

      En outre, le Conseil a examiné les observations sur les conditions d’admissibilité pour .MUSEUM comme décrit dans la spécification 12 par rapport aux exigences que les nouveaux candidats aux nouveaux gTLD de la communauté sont tenus d’inscrire dans leurs politiques en matière d’enregistrement. Le Conseil note que le registre prend les mesures nécessaires pour garantir que les politiques d’enregistrement soient cohérentes avec les autres TLD « communautaires ») par la mise en œuvre de restrictions sur les personnes ou entités pouvant enregistrer des noms de domaine .MUSEUM, de restrictions sur la façon dont les noms de domaine .MUSEUM peuvent être utilisés, les mécanismes d’application de l’admissibilité et la mise en place de procédures de post-validation pour protéger la crédibilité du TLD .MUSEUM. Bien que le Conseil reconnaisse les préoccupations soulevées sur la position de l’ICANN org pour permettre à .MUSEUM de mettre en place des exigences d’admissibilité à l’enregistrement en passant d’un TLD « sponsorisé » à un TLD « communautaire », le Conseil reconnaît la possibilité pour .MUSEUM de définir des conditions d’admissibilité au cours de la procédure de renouvellement du contrat comme d’autres TLD communautaires l’ont fait durant le processus de candidature. En tant que tel, l’opérateur de registre s’est engagé à maintenir les mêmes conditions d’admissibilité que les autres TLD communautaires ou jusqu’à un réexamen de la spécification 12 ait lieu et que les exigences d’admissibilité soient décidées par la communauté.

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

      L’approbation du contrat de renouvellement de registre de .MUSEUM par le Conseil d’administration offre des avantages techniques et opérationnels. Le fait que le renouvellement du contrat de registre de .MUSEUM exige l’utilisation de bureaux d’enregistrement accrédités ayant signé le contrat d’accréditation de bureau d’enregistrement (RAA) 2013 offre de nombreux avantages aux bureaux d’enregistrement et aux titulaires de noms de domaine et comprend d’autres améliorations présentes dans le contrat de registre des nouveaux gTLD. Cette décision est prise dans l’intérêt public dans la mesure où elle contribue à l’engagement de l’organisation de l’ICANN de renforcer la sécurité, la stabilité et la résilience du DNS.

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

      Aucun impact financier significatif n’est à prévoir suite à la signature du contrat de renouvellement de registre de .MUSEUM.

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

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

      Cette décision est conforme à l’intérêt public et à la mission de l’ICANN, dans la mesure où le rôle de l’ICANN dans la coordination du DNS inclut la passation de contrat avec les opérateurs de registre TLD, et cette action a examiné les commentaires publics dans l’exercice de ce rôle de coordination.

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

  2. Ordre du jour principal :

    1. Confirmation de l’objectif du fonds de réserve

      Attendu que, le Conseil et l’organisation de l’ICANN ont publié pour commentaire public une mise à jour de la justification et l’objectif souhaité au sujet du fonds de réserve de l’ICANN.

      Attendu que, le comité des finances du conseil (BFC) a examiné les observations présentées dans le cadre du processus de consultation publique, les réponses fournies par l’ICANN org, et les changements suggérés à la justification du fonds de réserve proposé sur la base des commentaires publics.

      Attendu que, certains commentaires reçus nécessitent une analyse plus approfondie pour déterminer la mesure dans laquelle ils devraient conduire à des modifications supplémentaires, y compris certains commentaires soumis concernant les fonctions Identificateurs techniques publics/IANA et ceux par rapport à une politique distincte pour le fonds de réserve.

      Attendu que, des travaux complémentaires ont été prévus afin d’élaborer des dispositions relatives à la gouvernance pour le Fonds de réserve et des actions pour reconstituer l’objectif de niveau du Fonds de réserve.

      Il est résolu (2018.02.04.09), que le Conseil d’administration adopte les modifications recommandées à la politique de l’ICANNInvestment qui comprennent une mise à jour de la justification du fonds de réserve et confirme son objectif actuel à un minimum de 12 mois de dépenses opérationnelles.

      Il est résolu (2018.02.04.10), que le Conseil demande au président-directeur général, ou son représentant, d’analyser plus à fond certains commentaires reçus et de déterminer dans quelle mesure d’autres changements dans la politique d’investissement devraient être envisagée.

      Fondements des résolutions 2018.02.04.09 à 2018.02.04.10

      Se fondant sur ses devoirs fiduciaires, et compte tenu de l’importante évolution que l’ICANN a vécue depuis la création de son fonds de réserve, le Conseil a déterminé que le fonds de réserve devrait être revu. Il a donc créé un groupe de travail qui, soutenu par l’organisation de l’ICANN, a évalué le fonds de réserve. Cette évaluation a permis de définir une mise à jour de la justification et un objectif actualisé pour le fonds de réserve. Compte tenu de l’importance jouée par le fonds de réserve sur la stabilité financière et la durabilité de l’ICANN, le Conseil d’administration a déterminé que la participation du public était nécessaire et a demandé à l’ICANN Org de publier l’analyse de la justification et l’objectif de niveau pour commentaire public.

      Le Conseil a également jugé que, une fois la justification et l’objectif de niveau mis à jour, après avoir pris en compte les commentaires du public, des travaux supplémentaires seraient nécessaires pour définir des mécanismes de gouvernance pour le fonds de réserve, et une stratégie afin de le faire passer de son niveau actuel à son objectif actuel.

      Cette décision est conforme à l’intérêt public et à la mission de l’ICANN, car elle qu’elle confirme un mécanisme fondamental soutenant la stabilité financière et la durabilité de l’ICANN. Maintenir un fonds de réserve approprié contribue à permettre à l’ICANN de continuer à s’acquitter de sa mission dans l’intérêt public.

      La mise à jour de la justification et de l’objectif du fonds de réserve, telle que reflétée dans la politique d’investissement de l’ICANN, aura un impact positif sur l’ICANN, car elle contribuera à améliorer la stabilité financière et la durabilité de l’ICANN ; elle fournit également à l’organisation la possibilité d’être responsable d’une manière transparente. Un impact fiscal est à prévoir sur l’ICANN et sur la communauté. Cela devrait avoir un impact positif sur la sécurité, la stabilité et la résilience du système des noms de domaine (DNS) dans la mesure où la stabilité financière et la durabilité de l’ICANN contribuent à sa capacité d’aider à assurer la sécurité, la stabilité et la résilience du DNS.

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

    2. Adoption du plan opérationnel et du budget IANA pour l’exercice fiscal 2019 (EF19)

      Attendu que, la version préliminaire du plan opérationnel et budget (OP&B) EF19 de l’IANA a été publié le 9 octobre 2017 pour commentaire public en conformité avec les règlements.

      Attendu que, les commentaires reçus par l’entremise du processus de consultation publique ont été examinés, fait l’objet d’une réponse. Ils ont été fournis aux membres du Comité des finances du conseil d’administration (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 un version finale de l’OP&B FY19 de l’IANA.

      Attendu que, par les statuts de l’ICANN, l’OB&B de l’IANA doit être adopté par le Conseil d’administration et ensuite affiché sur le site Web de l’ICANN.

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

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

      Fondements de la résolution 2018.02.04.11

      Conformément au chapitre 22, article 22.4 des statuts constitutifs de l’ICANN, le Conseil d’administration adopte un budget annuel et le publie sur le site Web de l’ICANN. Le 9 octobre 2017, les versions préliminaires de l’O&B EF19 des PTI et l’OP&B EF19 de l’IANA ont été publiées pour commentaire public. Le conseil d’administration des PTI a approuvé le budget des PTI le 9 janvier 2018, et ledit budget a servi de base au budget EF19 de l’IANA.

      Les versions préliminaires publiées de l’OP&B EF19 des PTI et l’OP&B EF19 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 EF19 de l’IANA. Là où cela était possible et approprié, ces apports ont été incorporés dans la version finale de l’OP&B ET19 de l’IANA proposée pour adoption.

      L’OP&B EF19 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é. 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.

    3. Traitement des candidatures de .CORP, .HOME et .MAIL dans le cadre du programme des nouveaux gTLD

      Attendu que, en mars 2013, le SSAC a émis le SAC057 : un rapport consultatif du SSAC sur les certificats de noms internes où le SSAC fait référence à la question des « collisions de noms » et indique au Conseil d’administration de l’ICANN les étapes à suivre pour atténuer le problème.

      Attendu que, le 18 mai 2013, le Conseil d’administration de l’ICANN a adopté une résolution concernant le SAC057, demandant une étude sur l’utilisation des TLD qui ne sont pas à l’heure actuelle délégués au niveau de la zone racine du DNS public dans les entreprises.

      Attendu que, en août 2013, Interisle Consulting Group a publié un rapport qui examinait l’historique des requêtes et a constaté que .HOME et .CORP étaient les deux TLD qui apparaissaient le plus parmi les domaines de premier niveau (TLD) dans les demandes.

      Attendu que, en août 2013, l’organisation de l’ICANN a demandé, en lien avec cette étude, la participation de la communauté au sens large dans l’élaboration d’une solution, et la version préliminaire d’un plan d’atténuation a été publiée pour commentaires publics avec le rapport d’Interisle. La version préliminaire du plan d’atténuation a qualifié .HOME et .CORP de chaînes à haut risque, proposant de ne pas les déléguer.

      Attendu que, le 7 octobre 2013, le Comité du programme des nouveaux gTLD (NGPC) du Conseil d’administration de l’ICANN a adopté une résolution visant à mettre en œuvre le plan d’atténuation lié à la gestion des occurrences de collisions de noms tel que proposé dans le « plan de gestion de l’occurrence de collisions de noms dans les nouveaux gTLD ».

      Attendu que, le 30 juillet 2014, le Comité du programme des nouveaux gTLD du Conseil d’administration de l’ICANN a adopté le cadre de gestion des collisions de noms. Dans ce cadre, .CORP, .HOME et .MAIL ont été qualifiées de chaînes à haut risque dont la délégation devait être indéfiniment reportée.

      Attendu que, le 28 octobre 2015, JAS Global Advisors a publié « Atténuer le risque de collisions dans l’espace de noms du DNS (rapport final) ». Les recommandations du rapport final étaient conformes aux recommandations formulées dans le rapport de première étape.

      Attendu que, en 2015, des membres du groupe de travail de l’IETF sur les opérations du DNS ont rédigé une proposition préliminaire sur Internet, la première étape de l’élaboration d’un RFC qui empêcherait les étiquettes .CORP, .HOME et .MAIL de faire l’objet d’une délégation au premier niveau du DNS, mais le groupe de travail et les auteurs de cette proposition préliminaire n’ont pas été en mesure d’obtenir un consensus sur les critères d’interdiction de la délégation des étiquettes et l’initiative visant à créer un RFC à cet égard a été abandonnée.

      Attendu que, le 24 août 2016, les candidats pour .CORP, .HOME et .MAIL ont écrit au Conseil d’administration de l’ICANN afin de lui demander « d’effectuer une analyse précise des mesures d’atténuation qui permettraient le déblocage de .HOME, .CORP et .MAIL. »

      Attendu que, le 2 novembre 2017, le Conseil d’administration de l’ICANN a demandé au Comité consultatif sur la sécurité et la stabilité de mener une étude approfondie et inclusive via des experts techniques (comme les membres de groupes de travail de l’IETF, les membres techniques de la GNSO ainsi que d’autres experts en technologies) afin de présenter des données, des analyses et des points de vue, et de donner un avis au Conseil d’administration au sujet des risques auxquels seraient soumis les utilisateurs et les systèmes finaux si les chaînes .CORP, .HOME et .MAIL étaient déléguées au sein de la zone racine, et de préciser les éventuelles mesures qui pourraient permettre d’atténuer les risques identifiés.

      Attendu que, le Conseil d’administration de l’ICANN a pris une résolution demandant au président-directeur général, ou à son ou ses représentants, de lui présenter des options afin de résoudre la question des candidatures au programme des nouveaux gTLD pour .CORP, .HOME et .MAIL, d’ici la première réunion du Conseil d’administration suivant l’ICANN60 à Abu Dhabi.

      Attendu que, le 13 décembre 2017, l’organisation de l’ICANN a présenté des options au conseil d’administration pour les candidatures au programme des nouveaux gTLD pour .CORP, .HOME, et .MAIL.

      Attendu que, le Conseil s’est engagé dans une discussion sur les avantages et les inconvénients des diverses options présentées pour gérer les candidatures. Les discussions du Conseil ont porté sur des questions d’équité, de savoir si les candidats avaient exprimé une préférence pour l’une quelconque des options, et la façon de gérer les candidatures pour .CORP, .HOME, et .MAIL qui avaient été retirées. En outre, le Conseil a discuté des incidences budgétaires des options présentées.

      Attendu que, le Conseil d’administration de l’ICANN n’a pas l’intention de déléguer les chaînes .CORP, .HOME, et .MAIL dans la série de 2012 du programme des nouveaux gTLD.

      Attendu que, le Conseil a estimé que les candidats n’étaient pas au courant avant la période de candidatures que les chaînes .CORP, .HOME, et .MAIL seraient identifiés à haut risque et que les délégations de ces chaînes seraient reportées indéfiniment.

      Il est résolu (2018.02.04.12) que le Conseil ordonne au président-directeur général, ou son représentant, que les candidatures pour .CORP, .HOME, et .MAIL ne soient pas examinées et, pour tenir compte de l’impact imprévu sur le traitement des candidatures, le Conseil ordonne au président-directeur général, dès le retrait des candidatures restantes pour .CORP, .HOME, et .MAIL, de fournir aux candidats un remboursement complet des frais de candidature au programme de nouveaux gTLD, frais s’élevant à 185 000 $.

      Fondements de la résolution 2018.02.04.12

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

      Précédemment, le Conseil d’administration a pris en considération les candidatures pour .CORP, .HOME et .MAIL et a choisi de reporter la délégation de ces noms pour une durée indéterminée à cause des collisions de noms. Une collision de noms survient lorsqu’une tentative de résolution d’un nom utilisé dans un espace de noms privés (p. ex., sous un domaine de premier niveau non délégué ou un nom court ou non qualifié) entraîne une requête auprès du système des noms de domaine (DNS). Lorsque les frontières administratives des espaces de noms publics et privés se chevauchent, la résolution de noms peut donner des résultats imprévus ou préjudiciables. L’introduction de tout nouveau nom de domaine dans le DNS, quel que soit le niveau crée les conditions pour que se produise éventuellement une collision de noms. Toutefois, le programme des nouveaux gTLD a apporté un regain d’attention à cette question des requêtes pour les TLD non délégués au niveau racine du DNS, car certaines des chaînes des nouveaux TLD ayant fait l’objet d’une candidature pourraient être identiques à celles du nom des étiquettes utilisées dans les réseaux privés (c.-à-d. .HOME, .CORP, et .MAIL). Un Internet sécurisé, stable et résilient est la priorité numéro un de l’ICANN. À l’appui de cette démarche, le Conseil de l’ICANN a pris l’engagement auprès de la communauté Internet d’atténuer et de gérer l’occurrence des collisions. Dans le cadre de cet engagement, l’organisation de l’ICANN a publié en juillet 2014, le cadre de gestion des occurrences de collisions de noms. Guidé par les recommandations présentes dans les rapports de la SSAC et de JAS Global Advisors, le cadre a recommandé que la délégation des chaînes .HOME, .CORP, et .MAIL soit reportée indéfiniment. Ces chaînes ont été identifiées comme présentant un « risque élevé ».

      Ces conclusions et recommandations ayant provoqué l’action précédente du Conseil sur .CORP, .HOME, et .MAIL n’ont pas changé et elles devraient continuer à être applicables à court terme. Dans la résolution du Conseil du 2 novembre 2017, celui-ci a demandé à l’ICANN org de lui offrir des options pour gérer les candidatures pour .CORP, .HOME, et .MAIL. L’ICANN org a présenté des options au conseil d’administration lors de la réunion du Conseil du 13 décembre 2017. Le Conseil a examiné les avantages et les inconvénients des options présentées et prend les mesures qui s’imposent en ce moment pour gérer les candidatures.

      Quelles sont les options à l’étude ? Quels sont les facteurs que le Conseil a trouvés significatifs ?

      Étant donné que le Conseil d’administration n’a pas l’intention de déléguer les chaînes .CORP,.HOME et .MAIL avant la fin de la série de 2012 du programme des nouveaux gTLD, les options présentées au conseil d’administration ont tenu compte de deux questions clés : quel type de remboursement devait être fourni aux candidats ? les candidats devaient-ils avoir priorité sur d’autres candidatures pour ces chaînes dans toute série ultérieure du programme des nouveaux gTLD ? Le Conseil a examiné un éventail d’options et de situations résultant de ces questions allant d’un remboursement standard et aucune priorité à un remboursement complet avec priorité.

      En discutant des options concernant le montant du remboursement, le conseil d’administration a considéré qu’un remboursement standard suivrait plus scrupuleusement les conditions que tous les candidats avaient acceptées dans le guide de candidature (AGB). Les candidats reconnaissent et acceptent les conditions générales de l’AGB établissant que l’ICANN a le droit de déterminer si elle souhaite traiter ou non une candidature pour de nouveaux gTLD, et qu’il n’existe aucune assurance que de nouveaux gTLD seront créés. La décision d’examiner, étudier et approuver une candidature pour établir un ou plusieurs gTLD, et de déléguer des nouveaux gTLD par la suite, est à l’entière discrétion de l’ICANN.

      Toutefois, le Conseil a également examiné des questions d’équité et reconnaît que, bien que la question de la collision de noms ait été décrite dans l’article 2.2.1.3 de l’AGB, les candidats ne savaient pas avant la période de candidatures que les chaînes .CORP, .HOME, et .MAIL seraient identifiés comme étant à haut risque. En outre, à la lumière des recommandations formulées dans le rapport du JAS, SAC062, SAC066, et du cadre de gestion des collisions de noms adoptés par le NGPC le 30 juillet 2014, la délégation de ces chaînes a été reportée indéfiniment.

      Le Conseil a conclu que cette situation était unique dans le programme des nouveaux gTLD. D’autres candidatures du programme des nouveaux gTLD n’ont pas été déléguées ou autorisées à poursuivre, en se basant sur des procédés des programmes de nouveaux gTLD. Par exemple, l’AGB a envisagé que toutes les candidatures ne réussiraient pas l’évaluation initiale ou suivante et tous les candidats étaient donc au courant de la possibilité de ne pas réussir la revue de ces chaînes et d’ainsi ne pas être admissibles à la délégation. Les candidats pour .CORP, .HOME, et .MAIL n’étaient pas au courant des années d’étude à venir sur la question des collisions de noms et qu’ainsi, à la fin du procédé, ils ne seraient pas admissibles à continuer dans le programme des nouveaux gTLD.

      En tant que tel, le Conseil a déterminé qu’il était approprié dans le cas présent de tenir compte de l’impact imprévu du traitement de la candidature et de fournir aux autres candidats de .CORP, .HOME, et .MAIL un remboursement complet des frais de candidature du programme des nouveaux gTLD de 185 000 $, lors du retrait de la candidature par le candidat.

      En ce qui concerne la priorité pour une série ultérieure, le Conseil a examiné plusieurs facteurs différents. Le Conseil a considéré qu’il n’y avait actuellement aucune indication que les chaînes .CORP, .HOME, et .MAIL seraient en mesure d’être déléguées à un quelconque moment à l’avenir. Bien que le Conseil d’administration ait pris une résolution demandant au Comité consultatif de l’ICANN pour la sécurité et la stabilité de procéder à une étude et de lui fournir un avis sur les risques et atténuations possibles de ceux associés à la délégation des chaînes .CORP, .HOME et .MAIL dans la racine, le résultat de cette étude ne sera pas disponible à court terme. Le Conseil a également examiné la complexité potentielle associée à l’établissement de procédures et règles d’octroi de la priorité et que cela peut être une question susceptible d’être traitée par le processus d’élaboration de politiques et non de l’action du Conseil. En se fondant sur ces motifs, le Conseil a décidé de ne pas accorder de priorité dans une série subséquente aux candidats de .CORP, .HOME, et .MAIL qui pourraient présenter une nouvelle demande.

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

      Pour adopter cette résolution, le Conseil d’administration a examiné, en plus des options fournies par l’ICANN org, divers matériaux, y compris, mais non limités aux :

      Cela a-t-il des impacts fiscaux ou des répercussions sur l’ICANN ?

      L’action du Conseil aura un impact fiscal sur l’ICANN. En examinant les options décrites ci-dessus, le Conseil a examiné l’impact entre fournir un remboursement standard ou un remboursement complet. L’estimation des coûts s’élève à 1 300 000,00 USD dans le cas d’un remboursement standard aux 20 candidats alors que le coût associé à un remboursement intégral est de 3 700 000 USD. Les fonds pour un remboursement complet proviendraient des fonds du programme des nouveaux gTLD, qui est constitué des frais de candidature perçus dans la série de 2012 (de tous les candidats). Bien que le montant du remboursement total diffère de la norme des remboursements prévus dans l’AGB, l’ICANN org a prévu que d’importants remboursements pourraient être émis pour les autres candidats du programme. En tant que tel, l’impact financier sur l’ICANN a été comptabilisé dans le plan opérationnel et budget. Le reste des fonds au moment de la publication du plan opérationnel et budget pour l’EF18 étaient de 95 800 000 USD.

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

      Comme prévu dans ses statuts constitutifs, l’ICANN a pour mission d’assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet. Cette action bénéficie à la communauté de l’ICANN, car elle assure la transparence et la prévisibilité aux candidats pour .CORP, .HOME, et .MAIL.

      Il s’agit d’une fonction administrative et organisationnelle de l’ICANN qui ne fait pas l’objet de consultation publique.

    4. Avis du GAC : Communiqué d’Abu Dhabi (novembre 2017)

      Attendu que, le Comité consultatif gouvernemental (GAC) s’est réuni lors de l’ICANN60 à Abu Dhabi, Émirats arabes unis (Émirats arabes unis), et a rendu un avis au Conseil d’administration de l’ICANN dans un communiqué [PDF, 596 Ko] le 1er novembre 2017 (« Communiqué d’Abu Dhabi »).

      Attendu que, le communiqué d’Abu Dhabi a fait l’objet d’un échange entre le Conseil d’administration et le GAC le 14 décembre 2017.

      Attendu que, dans un courrier [PDF, 976 Ko] du 6 décembre 2017, adressé au Conseil d’administration, le conseil de la GNSO a fourni des commentaires concernant l’avis du communiqué d’Abu Dhabi 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.

      Attendu que, le Conseil d’administration a élaboré une itération de la fiche de suivi pour répondre à l’avis du GAC émis dans le communiqué d’Abu Dhabi, en tenant compte de l’échange qui s’est effectué entre le Conseil d’administration et le GAC ainsi que des informations fournies par le conseil de la GNSO.

      Il est résolu (2018.02.04.13), que le Conseil d’administration adopte la fiche de suivi intitulée « Avis du GAC — communiqué d’Abu Dhabi : Actions et mises à jours (4 février 2018) » [PDF, 99 Ko] en réponse aux éléments de l’avis du GAC dans le communiqué d’Abu Dhabi.

      Fondements de la résolution 2018.02.04.13

      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é d’Abu Dhabi (1er novembre 2017), le GAC a émis à destination du conseil d’administration un avis sur : la protection des noms et sigles d’organisations intergouvernementales (OIG) dans les TLD génériques ; la possibilité d’une participation inclusive, éclairée et efficace au sein de l’ICANN ; le règlement général sur la protection des données (RGPD) et le WHOIS ; et les candidatures pour .AMAZON et chaînes connexes. Les statuts constitutifs de l 'ICANN prévoient que le Conseil tienne compte de l'avis du GAC en matière de politique publique pour la formulation et l'adoption de politiques. Au cas où le Conseil d'administration déciderait d’agir contrairement à l’avis du GAC, il est tenu d'en avertir ce dernier en indiquant les raisons pour lesquelles il a décidé de ne pas suivre son avis. 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.

      À ce stade, le Conseil d’administration prend des mesures pour répondre à l’avis du GAC émis dans le communiqué d’Abu Dhabi. Les décisions du Conseil d’administration sont décrites dans la fiche de suivi datée du 4 février 2018 [PDF, 99 Ko].

      En adoptant sa réponse à l’avis du GAC émis dans le communiqué d’Abu Dhabi, 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.

      Cette action s’inscrit dans la poursuite de la mission de l’ICANN, puisque le Conseil d’administration est tenu d’examiner en vertu des statuts constitutifs l’avis du GAC sur les questions de politique publique. C’est également dans l’intérêt public, car le Conseil réfléchit sur les vues du GAC ainsi que d’autres parties de la communauté dans la résolution de ces points en suspens de l’avis.

      Aucun impact financier associé à l’adoption de cette résolution n’est prévu.

      L'approbation de la résolution n'aura pas d'impact sur la sécurité, la stabilité ou la résilience du DNS.

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

    5. Prochaines étapes dans la révision du processus d’évaluation de la priorité communautaire — MISE À JOUR UNIQUEMENT

      Aucune résolution adoptée.

    6. Divers

      Aucune résolution adoptée.

Publié le 6 février 2016

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