Activités et réunions du Conseil d’administration
Procès-verbal | Réunion du Conseil d'administration de l'ICANN 18 mai 2013
Ce document a été traduit dans plusieurs langues dans un but purement informatif. Le texte original faisant foi (en anglais) peut être consulté sur : http://www.icann.org/en/groups/board/documents/minutes-18may13-en.htm
Une réunion extraordinaire du Conseil d'administration de l'ICANN a eu lieu le 18 mai 2012 à 2h00, heure locale à Amsterdam, Pays Bas.
Steve Crocker, président, a rapidement rappelé la séance à l'ordre.
Outre le vice-président, les administrateurs suivants ont participé à toute ou à une partie de la réunion : Sébastien Bachollet, Fadi Chehadé (Président-directeur général), Bertrand de La Chapelle, Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (Vice-président), Judith Vazquez et Kuo-Wei Wu
Les agents de liaison suivants du Conseil ont participé à toute ou à une partie de la réunion : Francisco da Silva (agent de liaison du TLG), Heather Dryden (agent de liaison du GAC), Ram Mohan (agent de liaison du SSAC) ; Thomas Narten (agent de liaison de l'IETF) ; et Suzanne Woolf (agent de liaison du RSSAC).
Les membres suivants du personnel ont participé à toute ou à une partie de la réunion : John Jeffrey, Conseiller juridique et secrétaire ; Akram Atallah, Directeur d'exploitation ; Sally Costerton, Tarek Kamel, David Olive, Megan Bishop, Michelle Bright, Samantha Eisner, Dan Halloran, Denise Michel, Cory Schruth, et Amy Stathos.
Jonne Soininen a participé de la réunion comme invité.
- Ordre du jour approuvé
- Ordre du jour principal
- Session exécutive
-
Ordre du jour approuvé :
Avant d'introduire l'ordre du jour approuvé, le président et le Président directeur général ont remercié le personnel de l'effort réalisé pour l'organisation de l'atelier.
Le président a présenté les questions incluses dans l'ordre du jour et a signalé que la demande de redélégation pour .ID avait été retirée de l'ordre du jour et que le point concernant le sous-comité pour le BGC avait été incorporé à l'ordre du jour principal. Sébastien Bachollet a proposé et Cherine Chalaby a appuyé la résolution ci-dessous, et le Conseil d'administration a pris la décision suivante :
Résolu, les résolutions ci-dessous correspondant au présent ordre du jour sont approuvées :
-
Approbation des procès-verbaux du Conseil d'administration
Résolu (2013.05.18.01), le Conseil d'administration approuve le compte-rendu de la réunion ordinaire du Conseil d'administration de l'ICANN du 11 avril 2013.
-
Calendrier d'approbation du budget de l'exercice fiscal 2014
Attendu que le budget de l'exercice fiscal 2014 est actuellement publié pour commentaires et que la période de commentaires publics sera clôturée le 20 juin 2013.
Attendu que, normalement l'ICANN approuve le budget de chaque année pendant une des réunions publiques de l'ICANN.
Attendu que cette année la réunion du milieu de l'année aura lieu à Durban, Afrique du sud, du 14 au 18 juillet 2013, après le début de l'exercice fiscal 2014 qui commence le 1er. juillet 2014.
Résolu (2013.05.18.02), le Conseil d'administration de l'ICANN a l'intention d'approuver le budget de l'exercice fiscal 2014 pendant la réunion publique de l'ICANN à Durban, Afrique du sud.
Résolu (2013.05.18.03), pour la période qui commence le 1er. juillet 2013 jusqu'à la date d'approbation du budget de l'exercice fiscal 2014, le Conseil d'administration enjoint au Président-directeur général d'administrer l'ICANN en ligne avec le budget de l'exercice fiscal 2014 publié pour consultation publique.
Fondements des résolutions 2013.05.18.02 et 2013.05.18.03
En vertu des statuts de l'ICANN, le budget de chaque année doit être approuvé vers la fin de l'exercice fiscal précédent (30 juin). Historiquement, cette approbation a lieu pendant la dernière réunion publique de l'ICANN de l'exercice fiscal (la réunion du milieu de l'année) qui est normalement prévue vers la fin juin. Cette année, la réunion du milieu de l'année aura lieu du 14 au 18 juillet 2013, c'est à dire, au début du prochain exercice fiscal.
La clôture du forum de commentaires publics pour le budget de l'exercice fiscal 2014 est prévue pour le 20 juin 2013. Étant donné que la clôture du forum aura lieu avant la fin de l'exercice fiscal, le temps pour analyser et considérer les commentaires publics (y compris les modifications potentielles du budget préliminaire incorporées après la révision des commentaires publics) avant de présenter le budget à la considération du Conseil d'administration est limité. En outre, plusieurs membres de la communauté de l'ICANN ont manifesté leur préférence pour que le budget annuel de l'ICANN soit approuvé lors d'une réunion publique de l'ICANN.
Dans le but d'allouer le temps suffisant à la révision des commentaires publics et pour que le Conseil prenne en considération les commentaires sur le budget, le personnel a recommandé au Comité des finances du Conseil (Board Finance Committee — BFC) que le budget de l'exercice fiscal 2014 soit approuvé par le Conseil d'administration pendant la réunion de Durban. Le BFC a donné son accord et a recommandé au Conseil de résoudre l'approbation du budget de l'exercice fiscal 2014 à Durban. Cette action met en valeur la responsabilité de l'ICANN vis-à-vis de la communauté puisque le Conseil donne ainsi une réponse aux préférences de la communauté d'approuver le budget pendant une réunion publique ; elle assure également que le Conseil puisse consacrer suffisamment de temps à l'analyse des commentaires de la communauté avant de prendre une décision sur le budget de l'exercice fiscal 2014.
Pour que l'ICANN puisse mener à bien ses activités au début de l'exercice fiscal 2014 qui commence le 1er. juillet 2014 jusqu'au jour où le Conseil approuve le budget, il sera nécessaire d'obtenir l'autorisation du Conseil de l'ICANN. En conséquence, le conseil autorise le Président-directeur général à travailler pendant cette période, conformément au budget de l'exercice fiscal 2014 ayant été publié pour consultation publique. Cette action permettra à l'ICANN de maintenir son activité jusqu'à ce que le budget de l'exercice fiscal 2014 soit formellement approuvé.
Une autre alternative serait que le Conseil prenne une décision le 30 juin 2013 ou même avant, et en dehors d'une réunion publique. En tout cas, cela ne serait pas souhaitable.
Le retard pour approuver le budget, accompagné par des mesures permettant à l'ICANN de poursuivre ses activités, n'est pas censé avoir un impact matériel sur les opérations financières prévues de l'organisation ou de la communauté. Cette décision n'est pas censée avoir d'incidence sur la sécurité, la stabilité ou la résilience du DNS.
Il s'agit d'une fonction administrative et organisationnelle qui n'exige pas de commentaires publics.
-
Emplacement de la réunion de l'ICANN d'octobre 2014 en Amérique du nord
Considérant que l'ICANN a l'intention de tenir sa troisième réunion de 2014 dans la région de l'Amérique du nord en conformité avec sa politique, et en ligne avec la résolution du Conseil du 20 décembre 2012 sur l'emplacement des réunions de 2014.
Attendu que le personnel a effectué une révision approfondie des possibles sièges pour tenir sa réunion en Amérique du nord, et que le site le plus approprié a été identifié à Los Angeles, Californie.
Attendu que le comité de participation publique du Conseil et le comité d'engagement des parties prenantes ont accordé que Los Angeles, Californie est le site approprié pour tenir la réunion de l'ICANN de 2014 aux États-Unis.
Résolu (2013.05.18.04), le Conseil approuve Los Angeles, Californie, comme l'emplacement de la réunion publique de l'ICANN 2014 en Amérique du nord, prévue du 12 au 17 octobre 2014.
Résolu (2013.05.18.05), la réunion publique de l'ICANN à Los Angeles en 2014 est désignée comme la réunion annuelle 2014 de l'ICANN.
Résolu (2013.05.18.06), le Conseil confirme sa résolution du 20 décembre 2012 qui autorise le Président-directeur général à prendre les mesures nécessaires pour administrer les conférences de 2014 de l'ICANN, y compris tous les contrats et déboursements nécessaires.
Fondements des résolutions 2013.05.18.04 — 2013.05.18.06
L'ICANN organise trois fois par an une réunion dans une région géographique différente (tel que défini dans ses statuts). La 51e réunion, prévue du 12 au 17 octobre 2014, aura lieu dans la région géographique d'Amérique du nord. Le personnel a identifié des emplacements disponibles et appropriés, et une analyse approfondie des sites a été réalisée afin d'assurer que ceux-ci respectent les critères de sélection du lieu de réunion. Sur la base de cette analyse, le personnel a recommandé que la 51e réunion de l'ICANN soit tenue à Los Angeles, Californie.
Le Conseil a examiné la recommandation du personnel d'organiser la réunion à Los Angeles, Californie, et il a été déterminé que la proposition satisfait aux principales conditions établies dans les critères de sélection du lieu de réunion utilisés pour guider le travail de sélection du site. Le processus de sélection de ce site n'a pas fait l'objet d'une consultation publique, étant donné que l'évaluation de la faisabilité d'une réunion faite par le personnel constitue la principale considération.
Les emplacements des réunions de mars 2014 (Singapour) et de juin 2014 (Londres) ont été approuvés par le Conseil le 20 décembre 2012. À titre d'analyse comparative, les installations de la réunion et le budget de production de la réunion de Singapour n'a pas dépassé 885 000 USD ; les installations de la réunion et le budget de production de la réunion de Londres n'a pas dépassé 734 000 USD ; et le budget de production de la réunion de Los Angeles n'est pas censé dépasser 568 000 USD. Ces chiffres concernent exclusivement les coûts d'autres réunions.
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. L'organisation de la réunion n'aura aucun impact sur la sécurité ou la stabilité du DNS.
Il s'agit d'une fonction administrative et organisationnelle pour laquelle des commentaires publics ne sont pas requis.
-
Proposition d'ACDR pour devenir un fournisseur UDRP
Attendu que le Centre arabe de résolution de litiges (Arab Center for Dispute Resolution — ACDR) a présenté une proposition pour être approuvé comme fournisseur UDRP.
Attendu que la proposition de l'ACDR a été publiée pour consultation publique le 28 septembre 2010 et qu'une version révisée a été publiée le 1er. mars 2013, dans laquelle les commentaires reçus ont été pris en compte ; l'ACDR a présenté une proposition révisée où le centre aborde une question finale ayant été soulevée dans le forum de commentaires publics du 1er. mars 2013.
Attendu que la proposition révisée de l'ACDR tient compte des éléments suggérés tel qu'il a été établi dans l'information concernant le processus d'approbation des fournisseurs de services de résolution de litiges.
Résolu (2013.05.18.07), le Conseil approuve la candidature d'ACDR pour devenir un fournisseur UDRP, et recommande au Président-directeur général, à travers le bureau du conseil juridique, de mener des discussions avec ACDR concernant son processus de provision de services UDRP.
Fondements de la résolution 2013.05.18.07
L'approbation de la candidature d'ACDR de la part du Conseil donne fin au travail d'ACDR (réalisé en coopération avec le personnel de l'ICANN) pour atteindre les standards et les éléments du processus d'approbation des fournisseurs UDRP (Politique uniforme de résolution de litiges relatifs aux noms de domaine). Cela renforce la responsabilité de l'ICANN à travers le respect qu'elle porte à ce processus. En outre, l'approbation du premier fournisseur UDRP situé au Moyen orient renforce la responsabilité de l'ICANN envers la communauté comme un tout, et cela renforce également le choix des plaignants en matière de résolution de litiges.
La proposition d'ACDR a été publiée pour commentaires publics à deux reprises. Tous les commentaires reçus ont été donnés à l'ACDR pour leur analyse. Certains commentaires contre, ont mentionné des questions telles que le niveau des frais, ce qui rentre dans le cadre de la portée d'ACDR. D'autres participants ont suggéré que l'ICANN pourrait développer des contrats avec chacun de ses fournisseurs UDRP comme un moyen d'obtenir l'uniformité parmi eux. Les contrats n'ont jamais été requis aux fournisseurs UDRP. Toutefois, en ce qui concerne la question de l'uniformité des fournisseurs, l'ACDR propose ce qui suit. En premier lieu, les domaines pouvant présenter des risques de non uniformité (par exemple les dates de début et fin des écrits) ont été modifiés ; deuxièmement, la proposition comprend maintenant une reconnaissance affirmative que si l'ICANN décide de modifier ses exigences vis-à-vis des fournisseurs, l'ACDR en fera le suivi ; et troisièmement, l'ACDR a révisé une partie spécifique des règles supplémentaires signalées dans plusieurs commentaires comme un risque potentiel pour l'uniformité. Voici une évolution positive qui aide à aborder les préoccupations concernant la capacité de l'ICANN pour que, dans l'avenir, l'identification des domaines susceptibles d'être modifiés et permettant d'améliorer l'uniformité parmi les fournisseurs devienne une obligation de l'ICANN.
Le fait que l'ICANN ait pris en considération la proposition d'ACDR montre la responsabilité de l'organisation vis-à-vis de la communauté. Après la demande de la communauté de réviser encore une fois la proposition avant son approbation, le Conseil a accepté et a demandé au personnel d'établir une nouvelle période de consultation publique. En outre, le Conseil a aussi demandé au personnel de présenter un rapport à la communauté sur la manière dont l'analyse préalable de l'ICANN portant sur l'uniformité des fournisseurs UDRP a été conclue. Par la suite, un document de synthèse sera publié et mis à disposition du public.
La décision d'assurer que le personnel de l'ICANN soit disponible pour travailler avec l'ACDR pour démarrer et maintenir son travail en tant que fournisseur est censée avoir un impact minimal sur les ressources de l'ICANN. Aucun impact sur la sécurité, la stabilité ou la résilience du DNS n'est à prévoir suite à cette décision.
Il s'agit d'une fonction administrative et organisationnelle pour laquelle des commentaires publics ont été reçus.
Tous les membres du Conseil d'administration ont approuvé les résolutions 2013.05.18.01, 2013.05.18.02, 2013.05.18.03, 2013.05.18.04, 2013.05.18.05, 2013.05.18.06 et 2013.05.18.07. Les résolutions ont été adoptées.
-
-
Ordre du jour principal :
-
Avis du SSAC sur les certificats de noms internes
Ram Mohan a fourni un rapport au Conseil sur les travaux du SSAC à propos des certificats internes de noms, notamment dans le rapport dénommé SAC 057. En bref, ce qui se passe c'est que dans le monde d'aujourd'hui il existe de nombreuses instances auxquelles on peut accéder à un intranet en tapant tout simplement http deux points double barre oblique [insertion du gTLD] pour avoir un intranet d'entreprise simplifié. On n'a pas besoin de taper le nom complet ou l'adresse réellement attribuée à cet intranet. Plusieurs noms ayant fait l'objet d'une candidature aux nouveaux gTLD pourraient appartenir à cette catégorie. Actuellement il y a des fournisseurs de SSL qui pourraient fournir un certificat valide de SSL pour un nom qui n'existe même pas.
Il y aurait un risque de collision ou de conflits entre des TLD, des noms de domaines non attribués, et des noms qui existent déjà et qui sont utilisés dans le monde. Il s'agit bien sûr d'une question quelque peu controversée étant donné que nous sommes à mi-chemin ou avec un bout de chemin déjà fait sur le parcours du processus des nouveaux gTLD. La recommandation du SSAC est donc de commencer une étude impliquant les données actuelles, qui intègre les données réelles, en les obtenant des opérateurs du serveur racine et des fournisseurs de certificats SSL, de recueillir ces données, les rassembler pour demander au personnel de travailler dessus et lui demander également de travailler conjointement avec le RSSAC pour que ce dernier puisse permettre la coordination avec les serveurs racine. En outre, il est recommandé de demander au personnel de consulter le SSAC lors de ce processus étant donné que ces travaux sont issus du SSAC. Enfin, demander au SSAC, après toute cette analyse et une fois l'étude terminée, s'il croit nécessaire de faire une mise à jour de ses recommandations au Conseil.
Le SSAC recommande que ce type de diligence puisse faire partie d'une plus grande expansion du DNS. Il y a eu un débat interne au sein du SSAC, pour savoir si cette résolution était vraiment nécessaire mais l'idée du processus était la suivante : 1. envoyer un message indiquant que le Conseil et l'ICANN sont bien centrés sur ce sujet et en délibèrent et 2. qu'il existe un souhait de coopération entre la structure des organisations de soutien (SO) et des comités consultatifs (AC) de l'ICANN, et l'extérieur. Ram a confirmé que ces travaux n'en sont qu'à leurs débuts ; selon leurs résultats, et sur instructions, il faudra peut-être envisager de voir comment gérer les chaînes ayant fait l'objet d'une candidature et qui peuvent provoquer ce type de collision. Les travaux commandés aujourd'hui permettront de recueillir des éléments factuels sur ce sujet.
Suzanne Woolf a confirmé que certains travaux sont déjà en cours et a signalé que ce travail crée un précédent quant à la coordination au sein du SSAC, du RSSAC, du personnel et parmi les consultants. Il y a plein d'excellents travaux qui sont déjà en cours.
Ray Plzak a comparé cette question à celle des adresses IP privées et des réseaux privés, et il a demandé s'il existait une coordination en cours établie avec l'IETF. Ray a mentionné que cela pouvait être prématuré pour le moment car cette question en est encore au stade de la conception et dépend des résultats obtenus, mais que l'IETF a des années d'expérience avec ce type de problèmes concernant l'aspect de l'adressage IP.
Thomas Narten a suggéré qu'une date limite claire serait utile dans la résolution, en bonne part pour permettre de comprendre le calendrier du déploiement des nouveaux gTLD.
Akram Atallah a confirmé que l'ICANN avait déjà délimité la portée de ces travaux et qu'il y aurait des informations à ce sujet en temps opportun, et il a proposé fin juin comme date possible d'établissement d'un rapport destiné au Conseil sur certains résultats de l'étude.
Ram a indiqué que d'autres dates pourraient également être incluses pour d'autres sections du travail. Le président a conseillé que le Conseil, au lieu de mettre des dates spécifiques qui ne donneront pas forcément de bons résultats, reconnaisse l'urgence et le côté sensible de cette question, et qu'il exige qu'une attention toute particulière soit portée à ces travaux.
George Sadowsky a signalé que ces travaux montrent l'importance du SSAC pour identifier des problèmes potentiels en matière de sécurité, y remédier et recommander des actions futures.
Bruce Tonkin a indiqué qu'il serait utile de recueillir certaines données en effectuant plusieurs enquêtes afin de les rendre disponibles pour d'autres utilisateurs.
Akram a confirmé qu'il comprenait que les données allaient être disponibles publiquement, même si les sources pouvaient ne pas toujours être identifiées dans la publication. Le président a signalé que cela permettra que l'analyse du SSAC apparaisse comme donnée disponible publiquement, et que cela était un plus.
Suzanne a indiqué que la crédibilité des résultats est très importante et que le principe établi doit être clair pour tout le monde.
Ray a souligné que le fait d'avoir un plan de collecte de données clair sera très important pour garantir que l'information obtenue soit la bonne. Ram a confirmé que le SSAC introduira des sources externes, le cas échéant, pour s'assurer que les données collectées soient bonnes. Le président a confirmé qu'il s'agissait de détails opérationnels qui seraient à la charge du personnel.
Le président a remercié le SSAC et le RSSAC de l'initiative prise à propos de cette question et a confirmé que le Conseil allait continuer la supervision de ces travaux. Le président a demandé d'effectuer une mise à jour pour la prochaine réunion.
Le Conseil a ensuite pris les décisions suivantes :
Attendu que la délégation des TLD visant à promouvoir la sécurité et une bonne expérience de l'utilisateur reste depuis longtemps une question majeure pour le Conseil de l'ICANN et pour la communauté internet mondiale.
Attendu que le 15 mars 2013, le Comité consultatif de l'ICANN sur la sécurité et la stabilité (SSAC) a publié le rapport SAC 057 : Rapport consultatif sur les certificats de noms internes
Attendu que les environnements locaux des entreprises peuvent inclure de fortes présomptions sur les noms de premier niveau existants au niveau de la racine d'un DNS public, et/ou avoir introduit des domaines de premier niveau locaux qui peuvent entrer en conflit avec des noms à déléguer au niveau racine du DNS public.
Attendu que, dans son rôle d'administrateur l'ICANN souhaite être en mesure de déterminer quels sont ces différends potentiels.
Résolu (2013.05.18.08), le Conseil d'administration de l'ICANN a demandé au Président-directeur général, en consultation avec le SSAC, d'effectuer une étude sur l'utilisation des TLD qui ne sont pas actuellement délégués au niveau de la racine du DNS public dans les entreprises. L'étude devrait considérer les impacts potentiels sur la sécurité des chaînes ayant fait l'objet d'une candidature à un nouveau gTLD liés à cette utilisation.
Résolu (2013.05.18.09), le conseil demande au SSAC d'assister l'ICANN dans la collecte des données et des observations liées aux opérations du serveur racine qui soient importantes pour cette étude, et de travailler avec les opérateurs des serveurs racine afin de permettre, le cas échéant, le partage de ces données et de ces observations dès que possible.
Résolu (2013.05.18.10), le Conseil enjoint au Président-directeur général de faire appel au Certificate Authority/Browser forum pour obtenir les statistiques sur la distribution des certificats de noms internes par domaine de premier niveau, dès que possible.
Résolu (2013.05.18.11), le Conseil demande au SSAC de considérer l'offre d'avis supplémentaires sur la base de son évaluation des questions identifiées dans l'étude de l'ICANN, dès que possible.
Justification des résolutions 2013.05.18.08 — 2013.05.18.11
Pourquoi le Conseil aborde-t-il cette question maintenant ?
La question des certificats internes identifiée par le SACC dans le SAC 057 est le symptôme que les entreprises ont des environnements locaux incluant de fortes présomptions sur le nombre statique des domaines de premier niveau et/ou ont introduit des domaines de premier niveau locaux qui pourraient présenter des conflits avec des noms à allouer. Peu importe la validité ou non de ces présomptions, l'ICANN, dans le but de jouer son rôle d'administrateur de manière proactive, souhaite déterminer quelles seraient les conséquences de ces conflits potentiels sur la sécurité et la stabilité, notamment vu que les candidatures aux nouveaux gTLD sont en cours d'évaluation pour leur délégation dans la racine. Cette étude constitue également un précédent pour les prochaines séries potentielles des TLD, où des études similaires pourraient être réalisées comme une question de diligence due.
Quelles sont les propositions à l'étude ?
Le Conseil d'administration de l'ICANN a demandé au Président-directeur général de commander une étude sur l'utilisation des TLD qui ne sont pas actuellement délégués au niveau de la racine du DNS public dans les entreprises. Cette étude devrait également tenir compte des conséquences potentielles sur la sécurité pour les chaînes ayant fait l'objet d'une candidature aux nouveaux gTLD liées à cette utilisation. En réalisant cette étude, le Conseil considère aussi de demander au RSSAC d'assister les opérateurs de serveurs racine en leur fournissant des statistiques et des observations. Enfin, le Conseil considère la possibilité de demander au SSAC d'évaluer s'il a un autre avis pour le Conseil réalisé sur la base de ses analyses.
Quelles parties prenantes ou autres ont été consultées ?
Le SSAC a présenté le « SAC 057 : Avis du SSAC sur les certificats de noms internes » à la communauté à Beijing. Suite à cela, le SSAC a reçu les commentaires de la communauté à ce sujet qui ont servi pour informer la demande du SSAC.
Quelles sont les préoccupations ou les questions soulevées par la communauté ?
Certains membres de la communauté ont manifesté leurs inquiétudes sur l'utilisation des TLD qui ne sont pas actuellement délégués au niveau racine du DNS public et sur l'impact sur les entreprises lorsque ces TLD sont délégués par l'ICANN dans les DNS publics. Il y en a qui ont demandé une évaluation de ces risques pour que la communauté puisse prendre des décisions en connaissance de cause. Il y en a qui ont dit que les études mettent en évidence qu'il n'existe pas de risque significatif pour la sécurité et la stabilité du DNS et qui ont encouragé l'ICANN à continuer avec l'évaluation et la délégation éventuelle de toutes les candidatures aux gTLD approuvées, sans tenir compte du conflit en matière de certificats de noms internes.
Quels documents importants le Conseil d'administration a-t-il examinés ?
Le rapport du SSAC sur les certificats de noms internes1 [PDF, 1.14 MB], Le rapport du SSAC sur les demandes non valides des demandes de domaines de premier niveau au niveau de la racine (15 novembre 2010 avec corrections)2 [PDF, 507 KB], Le rapport du comité sur la sécurité et la stabilité en matière d'extensibilité de la zone racine3 [PDF, 175 KB]
Quels sont les facteurs que le Conseil a trouvés significatifs ?
Pour décider cette action, le Conseil a pris en considération les recommandations du SACC dans les SAC 045, 046 et 057.
Y a-t-il des effets positifs ou négatifs pour la communauté ?
Les instructions données par le Conseil au personnel à travers le Président-directeur général pour effectuer une étude détaillée des risques liés à l'utilisation des TLD qui ne sont pas encore délégués au niveau racine du DNS public dans les entreprises provoquera un impact positif sur la communauté et améliorera la compréhension de la question en fournissant des informations supplémentaires des impacts sur la sécurité des chaînes ayant fait l'objet d'une candidature aux nouveaux gTLD par rapport à cette utilisation. Cela permettra à la communauté et au Conseil de comprendre plus en détail les questions potentielles pouvant affecter la sécurité et la stabilité si les TLD en conflit étaient délégués, ainsi que l'impact sur la fonctionnalité générale de l'ICANN.
Cela a-t-il un impact financier ou des répercussions sur l'ICANN (Plan stratégique, Plan opérationnel, Budget), sur la communauté ou sur le public ?
Cette décision n'est pas censée avoir d'impact sur les ressources de l'ICANN et la mise en place de ce travail peut donner lieu à des modifications des plans de mise en œuvre des nouveaux gTLD. Bien que l'étude elle-même ne soit pas censée avoir d'impact financier sur l'ICANN, la communauté ou le public, il est pourtant possible qu'elle puisse ne pas couvrir des risques en matière de sauvegardes spéciales pour les gTLD en conflit. Il est également possible que certains gTLD ne soient pas éligibles pour délégation.
Y a-t-il des questions de sécurité, de stabilité ou de résilience concernant le DNS ?
Le SAC057 a identifié plusieurs risques liés à la sécurité du DNS. Cette étude est censée fournir une approche quantitative du problème ainsi que des informations qui pourraient éclairer les prises de décision futures.
Il s'agit d'une fonction administrative et organisationnelle pour laquelle des commentaires publics ne sont pas requis. Toutefois, toutes les recommandations découlant du travail réalisé à travers cette résolution exigent d'avoir les commentaires de la communauté avant que le Conseil ne prenne une décision.
Tous les membres du Conseil d'administration ont approuvé les résolutions 2013.05.18.08 et 2013.05.18.11. Les résolutions ont été adoptées.
-
Demande de budget du SSAC
Ray Plzak a ensuite proposé et Judith Vazquez a appuyé la résolution proposée.
George Sadowsky a fait part du problème en signalant qu'il y avait certaines demandes budgétaires de la communauté qui ne pouvaient pas attendre l'approbation du budget global annuel. L'une de ces demandes provenait du SSAC et n'a pas été soumise à l'approbation avec un groupe précédent de demandes de la communauté. Toutefois, le Comité financier du Conseil pense que la demande de soutien aux déplacements pour que les membres du SSAC se rendent à la réunion de Durban est raisonnable et qu'elle devrait être approuvée ; c'est justement ce qui a été recommandé au Conseil d'administration.
Le président a signalé qu'il existe une structure de soutien des organisations et des comités consultatifs au sein de l'ICANN, et que leurs fonctions et leurs objectifs au sein de l'ICANN sont différents. En particulier en ce qui concerne les comités consultatifs (AC), chaque groupe est très différent des autres. En conséquence, il est difficile de trouver une formule pour gérer ce type de demandes, ou de traiter chaque comité consultatif comme s'il était identique aux autres. Il est important que le rôle de chaque AC soit pris en compte dans le cadre des demandes budgétaires, car nous valorisons le rôle et le temps consacré par chaque AC. Ici, le SSAC est formé par des experts indépendants qui conseillent l'ICANN en matière de sécurité et de stabilité, point qui représente une grande priorité pour l'ICANN.
Le Conseil a ensuite pris les décisions suivantes :
Attendu que, le 11 avril 2013 le Conseil a approuvé les demandes de budget des organisations de soutien et des comités consultatifs présentées sous la procédure accélérée pour être inclus dans le budget de l'exercice fiscal 2014.
Attendu que le Conseil n'a pas approuvé la demande du SSAC en matière de voyages supplémentaires pour la réunion de l'ICANN à Durban.
Résolu, (2013.05.18.12), le Conseil approuve maintenant la demande du SSAC pour un montant de 20 000 USD pour des déplacements supplémentaires destinés à la réunion de l'ICANN à Durban qui sera inclus dans le budget de l'exercice fiscal 2014 de l'ICANN dans le cadre de la procédure accélérée de demande de budget additionnel des SO/AC.
Tous les membres du Conseil ont approuvé la résolution 2013.05.18.12. La résolution a été adoptée.
Fondements de la résolution 2013.05.18.12
Les procédures accélérées de demande de budget additionnel des organisations de soutien et des comités consultatifs conduisant à l'approbation du budget plus tôt que d'habitude représentent un accommodement raisonnable pour des activités qui commencent au début de l'exercice fiscal 2014. Cette légère augmentation du processus d'approbation du budget établi de l'ICANN et de son calendrier permet de faciliter le travail de la communauté et du personnel de l'ICANN, et n'entraîne pas de dépenses supplémentaires.
En vertu de la recommandation du comité des finances du Conseil et à la lumière du rôle spécifique joué par le SSAC au sein de l'ICANN, cette décision est importante vis-à-vis du travail lié à la sécurité, la stabilité et la résilience du DNS, bien qu'aucun impact direct sur la sécurité, la stabilité et la résilience du DNS ne soit attendu suite à cette décision.
Il s'agit d'une fonction administrative et organisationnelle pour laquelle aucun commentaire public n'a été reçu.
-
Sous-comité du Comité de gouvernance du Conseil d'administration (BGC) pour les demandes de reconsidération liées aux nouveaux gTLD
Bruce Tonkin a présenté ce point, en signalant que pour toutes les questions à traiter, les membres du Conseil sont obligés à identifier des conflits potentiels et de les divulguer. Dans le cadre du programme des nouveaux gTLD, il y a aussi le Comité du programme des nouveaux gTLD qui permet d'identifier les membres qui pourraient avoir des conflits d'intérêt réels ou potentiels liés à ce programme. Au sein du Comité de gouvernance du Conseil, qui tient compte des demandes de reconsidération et fait ensuite des recommandations au Conseil, certains membres du BGC ne sont pas membres du Comité du programme des nouveaux gTLD. Maintenant qu'il y a des candidats insatisfaits des résultats du programme des nouveaux gTLD, ils commencent à formuler des demandes de reconsidération et on s'attend à ce que cela continue. En conséquence, le BGC peut traiter chaque demande au cas par cas pour déterminer les conflits, ou bien créer un sous-comité avec des membres du BGC appartenant déjà au Comité du programme des nouveaux gTLD, pour constituer le groupe de base des membres qui prendront en charge les demandes relatives aux nouveaux gTLD. Il existe une inquiétude concernant la détermination au cas par cas qui pourrait constituer une charge en raison du délai précis de réponse aux demandes de reconsidération. En conséquence, le BGC recommande de créer un sous-comité pour remplir cet objectif. Le sous-comité aurait la possibilité de faire participer d'autres membres du Conseil possédant une expertise sur certaines questions, le cas échéant. Les recommandations du BGC étant également publiées, cela pourrait représenter la dernière chance de recevoir des commentaires, avant que le Conseil ou le Comité du programme des nouveaux gTLD (NGPC) prennent une décision liée à une demande en particulier.
Ray Plzak a posé une question concernant les exigences quant au quorum et la taille optimale du sous-comité. Ray a signalé l'inquiétude soulevée du fait que le sous-comité soit constitué de 3 membres alors que seulement 2 sont nécessaires pour atteindre le quorum, ce qui représenterait seulement deux membres du BGC sur six ayant la possibilité de soulever un problème d'optique.
Le conseiller juridique et le secrétaire ont confirmé que le BGC pourrait recommander la taille optimale. La recommandation ici est qu'il soit constitué par des membres du BGC.
Bruce a confirmé que le BGC recherche l'approbation du Conseil uniquement dans le but de constituer actuellement le sous-comité et qu'il ne nomme pas encore les membres du sous-comité, de sorte que ces questions pourront être débattues ultérieurement.
George Sadowsky a signalé qu'il ne voyait pas la nécessité de créer un sous-comité puisque le problème évoqué dans une demande de reconsidération pourrait être celui où l'un des membres exclus n'a en réalité aucun conflit. Le défaut devrait permettre la récusation lorsqu'il y a un conflit et non pas prédéterminer le conflit.
Bruce a confirmé que cela créait une situation d'adhésion (opt-in) par rapport à celle de retrait (opt-out). Il s'agira d'un comité permanent pouvant être convoqué avec un préavis très court, ce qui est parfois nécessaire pour les demandes de reconsidération. Maintenant, tout le BGC doit recevoir ce préavis et participer à une réunion, et ensuite déterminer les conflits, ce qui prend beaucoup de temps. C'est une mesure efficace, comme c'est le cas pour le NGPC.
George a signalé que c'était différent pour le NGPC qui couvre un large éventail de questions. Les demandes de reconsidération sont traitées à partir d'optiques individuelles.
Bruce a confirmé que dans aucun cas il est supposé que toutes les personnes présentes au NGPC sont libres de conflit d'intérêts sur une question donnée ; le conflit doit être déterminé dans chaque cas, ainsi que les questions à traiter auprès du Conseil.
Olga Madruga Forti a signalé qu'un sous-comité pourrait présenter des avantages et qu'il serait important pour tous les membres du Conseil de prendre des décisions sans aucun indice de conflit d'intérêt. La possibilité pour des administrateurs en conflit de fournir une expertise semble remettre ceci en question et Olga a demandé davantage d'informations sur ce processus.
Bruce a confirmé qu'il pourrait y avoir des situations où un administrateur n'aurait vraiment aucun conflit d'intérêt sur un sujet — alors il pourrait y participer. De même, si un administrateur possède l'expertise dans un domaine donné, il pourrait donner son avis en la matière si le Conseil le lui demandait. Cela va vers la structure opt-in en opposition à la structure opt-out.
Le président a déclaré que l'une des inquiétudes peut provenir du fait que ce n'est que du ressort du sous-comité ou du Conseil d'inviter un directeur intéressé en raison de son expertise. Il peut s'avérer utile de fournir un mécanisme à l'administrateur pour identifier lui-même le domaine d'expertise.
Bertrand de la Chapelle a signalé qu'il était clair que le Conseil tente de bien faire les choses et d'illustrer le comportement correct. Mais ceci soulève aussi des questions administratives relatives au quorum, au temps et à l'efficacité. Bertrand a compris la position de George, à savoir que les conflits liés aux demandes de reconsidération découlant du programme des nouveaux gTLD pourraient être différentes des conflits généralement liés au programme. La reconsidération en soi nécessite des décisions au cas par cas, et l'opt-out est probablement la meilleure voie à suivre. Il existe également la possibilité, tel que Ray l'a suggéré, que les questions liées au quorum, combinées à des questions concernant des conflits spécifiques, pourraient empêcher tout le monde d'écouter la demande. Si une approche opt-in était finalement choisie, elle serait améliorée en fournissant davantage de précisions sur le processus d'engagement des experts dont parlait Bruce.
Le Conseil a ensuite discuté de certaines modifications proposées pour la résolution et Mike Silber a demandé si cette question devait être renvoyée au BGC, au lieu de modifier la résolution à la volée.
Les membres du Conseil ont ensuite accordé qu'il serait convenable que le BGC contribue davantage à ce sujet et qu'un vote sur la résolution proposée ne devrait pas avoir lieu cette fois-ci.
-
Questions diverses
Le Conseil a reçu un bref rapport du président et du directeur général concernant une idée de création de Groupes présidentiels consultatifs sur des sujets particuliers qui pourraient permettre d'intégrer une orientation pour des questions stratégiques auxquelles l'organisation est confrontée. Cet élément est encore à l'étape embryonnaire et le président et le directeur général ont ensuite accordé de consulter les membres intéressés du Conseil pour permettre de guider et d'encadrer les travaux de ces comités. Le président et le directeur général ont également informé le Conseil de l'élaboration d'un processus d'identification d'une approbation pour les besoins de déplacements à l'étranger du Conseil pour les réunions de l'ICANN et les ateliers du Conseil, ainsi que pour l'utilisation du processus du Bureau des conférenciers de l'ICANN.
-
-
Session exécutive
Le Conseil a procédé à une séance à huis clos sans la présence du personnel. Le Conseil a entrepris les actions suivantes lors de sa séance exécutive :
-
Prime de risque du PDG
Lorsque le Président-directeur général a été embauché, il lui a été accordé un salaire de base plus une prime de risque sur sa rémunération globale. De la même manière que tout le personnel de l'ICANN, le Président-directeur général est évalué par rapport aux objectifs spécifiques établis en coordination avec le comité des rémunérations.
À Beijing, le comité des rémunérations a recommandé au Conseil d'approuver le paiement de la prime de risque au Président-directeur général pour le deuxième trimestre de l'exercice fiscal 2013, et le Conseil a été d'accord avec cette recommandation.
Bien que cette action ait un impact financier sur l'ICANN, celui-ci a été considéré dans le budget de l'exercice fiscal 2013. Cette décision du Conseil n'est pas censée avoir d'incidence sur la sécurité, la stabilité ou la résilience du système de noms de domaine.
Il s'agit d'une fonction administrative et organisationnelle de l'ICANN qui ne nécessite pas de consultation publique.
Fondements de la résolution 2013.05.18.xx
Attendu que chacun des membres du Conseil d'administration a confirmé ne pas avoir de conflits d'intérêt concernant le fait d'établir le montant de la prime de risque du Président-directeur général pour le deuxième trimestre l'exercice fiscal 2013.
Attendu que le comité des rémunérations a recommandé au Conseil d'approuver le paiement au Président-directeur général de sa prime de risque du deuxième trimestre de l'exercice fiscal 2013.
Résolu (2013.05.18.13), le Conseil approuve le paiement au Président-directeur général de sa prime de risque du deuxième trimestre de l'exercice fiscal 2012.
Résolu (2013.05.18.14), les points spécifiques de cette résolution resteront confidentiels, définis comme « action concernant la problématique du personnel ou de l'emploi », conformément à l'article III, section 5.2 des statuts de l'ICANN.
-
Résolution confidentielle
[Résolution supprimée]
Résolu (2013.05.18.18), les points spécifiques de cette résolution [Résolutions 2013.05.18.15, 2013.05.18.16 et 2013.05.18.17] seront confidentiels comme une « action concernant la problématique du personnel ou de l'emploi », en vertu de l'article III, section 5.2 des statuts de l'ICANN, et la totalité de la résolution restera confidentielle en vertu des mêmes statuts en attendant la décision du Président-directeur général de rendre publique la partie non-confidentielle de la résolution.
Justification des résolutions 2013.05.18.15 — 2013.05.18.18
[Fondements supprimés]
-
1 Voir http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf [PDF, 1.14 MB]
2 Voir http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf [PDF, 507 KB]
3 Voir http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf [PDF, 175 KB]