Skip to main content
Resources

Résolutions approuvées par le Conseil d’administration | Réunion extraordinaire du Conseil d’administration de l’ICANN

Cette page est disponible en:

Ce document a été traduit dans plusieurs langues dans un but purement informatif. Le texte original faisant foi (en anglais) peut être consulté sur : http://www.icann.org/en/groups/board/documents/resolutions-28aug12-en.htm

 

  1. Ordre du jour approuvé :
    1. Approbation des procès-verbaux du Conseil d'administration
    2. Confirmation du rapport des actions de consentement écrit
    3. Demande de délégation du domaine مليسيا. (« Maleesya ») qui représente la Malaisie en arabe
      1. Fondements de la résolution 2012.08.28.03
    4. Redélégation de .rw
      1. Fondements de la résolution 2012.08.28.04
    5. Emplacement de la réunion 2013 en Afrique
      1. Fondements de la résolution 2012.08.28.05
  2. Ordre du jour principal :
    1. Recommandation du BGC sur la demande de reconsidération 12-2
      1. Fondements des résolutions 2012.08.28.06 – 2012.08.28.07
  3. Session exécutive

 

  1. Ordre du jour approuvé :

    1. Approbation des procès-verbaux du Conseil d'administration

      Résolu (2012.08.28.01), le Conseil approuve les procès-verbaux de la Réunion du Conseil de l'ICANN du 23 juin 2012.

    2. Confirmation du rapport des actions de consentement écrit

      Résolu (2012.08.28.02) le Conseil d'administration confirme le rapport des actions de consentement écrit d'août 2012.

    3. Demande de délégation du domaine مليسيا. (« Maleesya ») qui représente la Malaisie en arabe

      Considérant que, ‎مليسيا. (« Maleesya »), codé comme « xn--mgbx4cd0ab », est une chaîne qui a été jugée représenter à juste titre la Malaisie à travers la procédure IDN accélérée.

      Considérant que l'ICANN a reçu une demande de délégation de ‎مليسيا. à MYNIC Berhad.

      Considérant que l'ICANN a examiné la demande et a déterminé que la délégation proposée répond aux intérêts des communautés Internet locales et mondiales ;

      Résolu (2012.08.28.03), la délégation proposée du domaine مليسيا. à MYNIC Berhad est approuvée.

      Fondements de la résolution 2012.08.28.03

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

      Le personnel soumet à la considération du Conseil les requêtes de délégation et redélégation des domaines de code de pays. Après avoir satisfait les demandes du personnel en fournissant une candidature suffisamment complète, le candidat a une probabilité raisonnable d'obtenir l'approbation du Conseil. Conformément aux engagements de l'ICANN visant à effectuer de manière efficiente le traitement des demandes liées à la fonction IANA et, notamment, à la zone racine DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée extraordinaire.

      Quelle est la proposition à l'étude ?

      Il est proposé d'approuver la demande à l'IANA de changer ou de désigner l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) d'un domaine de premier niveau de code de pays. Conformément à la pratique établie, l'implication du Conseil de l'ICANN dans la décision portant sur la prise en compte de telles demandes reste une étape de ce processus multi-étapes.

      Quelles parties intéressées ou autres ont été consultées?

      Dans le cadre de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (le cas échéant), et d'autres parties directement concernées. Conformément à la pratique de l'ICANN de maintenir la confidentialité des demandes de modification de la zone racine, l'ICANN n'a pas effectué de consultation ouverte sur cette question.

      Quelles sont les préoccupations ou les questions soulevées par la communauté ?

      Les inquiétudes ou questions concernant cette demande sont évoquées dans le rapport public qui sera publié en accompagnement de cette décision. Ce rapport, qui sera publié au site Web de l'IANA http://www.iana.org/ est censé mener à bonne fin le traitement définitif de ces demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

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

      Le Conseil évalue les demandes sur la base d'un ensemble de critères d'intérêt public. Ce critère vise à établir l'admissibilité des codes de pays (p. ex. énumérés dans la norme ISO 3166-1) ; à établir la proposition d'un administrateur soutenu par la communauté Internet locale ; la compétence opérationnelle et technique de l'opérateur proposé ; l'opération de l'administrateur proposé depuis une base locale et en vertu de la loi locale ; à établir qu'il opère de manière juste et équitable ; à ce que, au cas où il y aurait un transfert des opérations, un plan approprié soit mis en place pour préserver la continuité de la stabilité du domaine ; et à établir que l'action soit compatible avec toutes les règlementations et les lois locales applicables. Lors du processus de collecte d'informations réalisé par le personnel, le candidat est prié de fournir un ensemble de documents à l'appui liés à ces différents aspects. Toute information pertinente sur ces documents fournis et d'autres recherches du personnel est adressée au Conseil et publiée dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

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

      Le Conseil tient compte des facteurs décrits dans le rapport public, à la lumière des principes fondamentaux de délégation de domaine de code de pays décrits ci-dessus.

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

      L'approbation en temps opportun des administrateurs de noms de domaine de code de pays répondant aux divers critères d'intérêt public est positive vis-à-vis de la mission globale de l'ICANN et les communautés locales, dont les domaines de premier niveau de code de pays sont désignés pour desservir.

      Y a-t-il un impact fiscal ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?

      La gestion de délégations des codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et le processus de délégation ne devrait pas produire une variation significative des dépenses prévues. L'ICANN n'est pas censé évaluer l'impact financier des opérations internes des domaines de premier niveau de code de pays dans un pays donné ; l'ICANN doit seulement s'assurer que l'opérateur réside dans le pays et qu'il possède les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement la gestion du domaine.

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

      Pour les délégations de domaines de premier niveau de code de pays, l'ICANN cherche à approuver uniquement les demandes dont tout inconvénient raisonnable a été résolu de façon satisfaisante, et dont le nouvel administrateur proposé a fait preuve d'un niveau de compétences opérationnelles et techniques suffisant pour minimiser toute éventuelle difficulté.

    4. Redélégation de .rw

      Attendu que RW est le code de pays de deux lettres correspondant au Rwanda dans la liste ISO 3166-1.

      Considérant que l'ICANN a reçu une demande de redélégation de .RW en faveur de l'association des communications de l'information et la technologie du Rwanda ;

      Considérant que l'ICANN a examiné la demande et a déterminé que la redélégation proposée répond aux intérêts des communautés Internet locales et mondiales ;

      Résolu (2012.08.28.04), la redélégation proposée du domaine .RW à l'association des communications de l'information et la technologie du Rwanda est approuvée.

      Fondements de la résolution 2012.08.28.04

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

      Le personnel soumet à la considération du Conseil les requêtes de délégation et redélégation des domaines de code de pays. Après avoir satisfait les demandes du personnel en fournissant une candidature suffisamment complète, le candidat a une probabilité raisonnable d'obtenir l'approbation du Conseil. Conformément aux engagements de l'ICANN visant à effectuer de manière efficiente le traitement des demandes liées à la fonction IANA et, notamment, à la zone racine DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée extraordinaire.

      Quelle est la proposition à l'étude ?

      Il est proposé d'approuver la demande à l'IANA de changer ou de désigner l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) d'un domaine de premier niveau de code de pays. Conformément à la pratique établie, l'implication du Conseil de l'ICANN dans la décision portant sur la prise en compte de telles demandes reste une étape de ce processus multi-étapes.

      Quelles parties intéressées ou autres ont été consultées?

      Dans le cadre de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (le cas échéant), et d'autres parties directement concernées. Conformément à la pratique de l'ICANN de maintenir la confidentialité des demandes de modification de la zone racine, l'ICANN n'a pas effectué de consultation ouverte sur cette question.

      Quelles sont les préoccupations ou les questions soulevées par la communauté ?

      Les inquiétudes ou questions concernant cette demande sont évoquées dans le rapport public qui sera publié en accompagnement de cette décision. Ce rapport, qui sera publié au site Web de l'IANA http://www.iana.org/ est censé mener à bonne fin le traitement définitif de ces demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

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

      Le Conseil évalue les demandes sur la base d'un ensemble de critères d'intérêt public. Ce critère vise à établir l'admissibilité des codes de pays (p. ex. énumérés dans la norme ISO 3166-1) ; à établir la proposition d'un administrateur soutenu par la communauté Internet locale ; la compétence opérationnelle et technique de l'opérateur proposé ; l'opération de l'administrateur proposé depuis une base locale et en vertu de la loi locale ; à établir qu'il opère de manière juste et équitable ; à ce que, au cas où il y aurait un transfert des opérations, un plan approprié soit mis en place pour préserver la continuité de la stabilité du domaine ; et à établir que l'action soit compatible avec toutes les règlementations et les lois locales applicables. Lors du processus de collecte d'informations réalisé par le personnel, le candidat est prié de fournir un ensemble de documents à l'appui liés à ces différents aspects. Toute information pertinente sur ces documents fournis et d'autres recherches du personnel est adressée au Conseil et publiée dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

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

      Le Conseil tient compte des facteurs décrits dans le rapport public, à la lumière des principes fondamentaux de délégation de domaine de code de pays décrits ci-dessus.

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

      L'approbation en temps opportun des administrateurs de noms de domaine de code de pays répondant aux divers critères d'intérêt public est positive vis-à-vis de la mission globale de l'ICANN et les communautés locales, dont les domaines de premier niveau de code de pays sont désignés pour desservir.

      Y a-t-il un impact fiscal ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?

      La gestion de délégations des codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et le processus de délégation ne devrait pas produire une variation significative des dépenses prévues. L'ICANN n'est pas censé évaluer l'impact financier des opérations internes des domaines de premier niveau de code de pays dans un pays donné ; l'ICANN doit seulement s'assurer que l'opérateur réside dans le pays et qu'il possède les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement la gestion du domaine.

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

      Pour les délégations de domaines de premier niveau de code de pays, l'ICANN cherche à approuver uniquement les demandes dont tout inconvénient raisonnable a été résolu de façon satisfaisante, et dont le nouvel administrateur proposé a fait preuve d'un niveau de compétences opérationnelles et techniques suffisant pour minimiser toute éventuelle difficulté.

    5. Emplacement de la réunion 2013 en Afrique

      Considérant que, l'ICANN a l'intention d'organiser sa deuxième réunion de 2013 dans la région Afrique conformément à sa politique.

      Attendu que l'autorité du nom de domaine .za s'est proposée pour accueillir la réunion de l'ICANN en Afrique planifiée pour 2013.

      Considérant que, le personnel a effectué une révision approfondie de la proposition faite par l'Autorité du nom de domaine .za et l'a estimée acceptable.

      Attendu que le Comité des finances du Conseil a approuvé le budget pour la Réunion de l'ICANN 2013 en Afrique, comme proposé.

      Attendu que le comité de participation publique du Conseil d'administration s'occupe de la coordination de la révision de la proposition du personnel et soutient la proposition de l'emplacement de la réunion 2013 de l'ICANN en Afrique.

      Résolu (2012.08.28.05), le Conseil accepte la proposition de l'autorité du nom de domaine .za et approuve que la réunion 2013 de l'ICANN en Afrique ait lieu à Durban, Afrique du sud, du 14 au 19 juillet 2013, avec un budget ne dépassant pas 2 472 000 USD.

      Fondements de la résolution 2012.08.28.05

      Dans le cadre du calendrier de réunions publiques de l'ICANN, l'ICANN organise trois fois par an une réunion dans une région géographique différente (tel que défini dans les statuts de l'ICANN). Exceptionnellement, la troisième réunion de l'exercice fiscal 2013 sera cette fois-ci organisée pendant l'exercice fiscal 2014. La 47ème réunion, prévue du 14 au19 juillet 2013, doit avoir lieu dans la région géographique de l'Afrique. Un appel à recommandations pour établir le lieu de la réunion en Afrique a été publié le 25 avril 2011. De nombreuses propositions ont été reçues.

      Le personnel a soigneusement examiné toutes les propositions et a préparé un document identifiant celles satisfaisant aux critères de sélection du lieu de réunion. Sur la base des propositions et des analyses, le personnel a recommandé que la 47ème réunion de l'ICANN soit tenue à Durban, Afrique du sud.

      Le Conseil a examiné la recommandation du personnel d'organiser la réunion à Durban, Afrique du sud, et 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. Outre l'appel aux recommandations, le processus de sélection de sites ne fait pas l'objet d'une consultation publique, étant donné que l'évaluation par le personnel de la faisabilité d'une réunion dans un site donné constitue la principale considération.

      L'organisation de la réunion ainsi que les aides aux frais de déplacement qui pourront s'avérer nécessaires auront un impact financier sur l'ICANN, ainsi que sur la communauté, car cela implique des frais de voyage pour certains participants à la réunion. Cet impact est à prévoir indépendamment du lieu de tenue de la réunion. La tenue de la réunion n'aura aucun impact sur la sécurité ou la stabilité du DNS.

  2. Ordre du jour principal :

    1. Recommandation du BGC sur la demande de reconsidération 12-2

      Attendu que le comité de gouvernance du Conseil a analysé la demande de reconsidération 12-2 présentée par le regroupement de la propriété intellectuelle concernant la décision du Conseil du 6 mai 2012 portant sur la publication des données Whois pour certains enregistrements dans le registre .CAT (http://www.icann.org/fr/groups/board/documents/resolutions-06may12-fr.htm#1.2).

      Attendu que le BGC recommande que la demande de reconsidération 12-2 devait être refusée.

      Attendu que la demande de reconsidération 12-2 et la recommandation du BGC ont été publiées dans le site Web de l'ICANN http://www.icann.org/en/groups/board/governance/reconsideration.

      Résolu (2012.08.28.06), le Conseil adopte la recommandation du BGC pour que la demande de reconsidération 12-2 soit refusée car la demande n'a pas identifié l'information matérielle dont le Conseil n'aurait pas tenu compte pour prendre la décision du 6 mai 2012.

      Résolu (2012.08.28.07), le Conseil donne des instructions au secrétaire d'amender la clause Attendu que antérieure à la résolution 2012.05.06.02 pour supprimer la suggestion d'une interdiction globale de la publication des données Whois pour les registrants individuels, et pour refléter plus précisément la portée de l'amendement à l'accord du registre .CAT ayant été demandé et approuvé.

      Fondements des résolutions 2012.08.28.06 – 2012.08.28.07

      En vertu des statuts de l'ICANN, le Comité de gouvernance du Conseil doit évaluer les demandes de reconsidération et faire des recommandations au Conseil d'administration. Voir article IV, section 3 des statuts. Le Conseil a révisé et analysé en profondeur la recommandation du BGC concernant la demande de reconsidération 12-2 et considère que l'analyse est adéquate.

      Le Conseil croit aussi que, pour garantir la responsabilité et la transparence de l'ICANN, il est essentiel d'assurer que la rédaction des résolutions reflète exactement la portée des décisions prises par le Conseil d'administration. Ici, une clause « attendu que » de la résolution 2012.05.06.02 a été identifiée comme excédant les limites de l'amendement demandé et approuvé par le Conseil. En conséquence, une modification à la clause « attendu que » conformément à l'engagement de l'ICANN vis-à-vis de la responsabilité reflète mieux la portée de l'amendement demandé et obtenu. La modification à la clause « attendu que » n'a aucun impact sur la portée actuelle de la décision du Conseil du 6 mai 2012.

      Le fait d'avoir un processus de reconsidération à travers lequel le BGC effectue une révision et recommande l'approbation du Conseil affecte positivement la transparence et la responsabilité de l'ICANN. Cette approche permet à la communauté de s'assurer que le personnel et le Conseil agissent dans le respect des politiques, des règlementations et des statuts constitutifs de l'ICANN. L'adoption de la recommandation du BGC n'a aucun impact financier sur l'ICANN et n'aura pas d'impact négatif sur la sécurité systémique, la stabilité et la résilience du système de noms de domaine.

  3. Session exécutive

    Le Conseil a conduit une partie confidentielle de la réunion dans laquelle d'autres résolutions ont été votées (2012.08.28.C1 et 2011.08.28.C2). Ces résolutions resteront confidentielles comme une « action concernant la problématique du personnel ou de l'emploi », conformément l'article III, section 5.2 des statuts de l'ICANN.

resolutions-28aug12-fr.pdf  [276 KB]

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