Skip to main content
Resources

Résolutions proposées par le Conseil d'administration | Réunion ordinaire 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-18may13-en.htm

 

  1. Ordre du jour approuvé
    1. Approbation des procès-verbaux du Conseil d'administration
    2. Calendrier d'approbation du budget de l'exercice fiscal 2014
      1. Fondements des résolutions 2013.05.18.02 et 2013.05.18.03
    3. Emplacement de la réunion de l'ICANN d'octobre 2014 en Amérique du nord
      1. Fondements des résolutions 2013.05.18.04 – 2013.05.18.06
    4. Proposition d'ACDR pour devenir un fournisseur UDRP
      1. Justification de la résolution 2013.05.18.07
  2. Ordre du jour principal
    1. Avis du SSAC sur les certificats de noms internes
      1. Justification des résolutions 2013.05.18.08 – 2013.05.18.11
    2. Demande de budget du SSAC
      1. Justification de la résolution 2013.05.18.12
  3. Session exécutive
    1. Prime de risque du PDG
      1. Fondements de la résolution 2013.05.18.13 – 2013.05.18.14
    2. Résolution confidentielle
      1. Justification des résolutions 2013.05.18.15 – 2013.05.18.18

 

  1. Ordre du jour approuvé :

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

    2. 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 de manière cohérente 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 eu 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.

    3. 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 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 51ème 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 51ème. 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 ne fait pas toujours 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 exclusivemenet les coûts d'autres réunions.

      Les frais d'organisation de la réunion ainsi que les aides aux déplacements 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 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.

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

      Justification 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 portant sur des 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 à 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 soit une obligation de l'ICANN.

      Le fait que l'ICANN ait pris en considération la proposition d'ACDR montre la responsabilité de l'ICANN 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.

  2. Ordre du jour principal :

    1. Avis du SSAC sur les certificats de noms internes

      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 attendu que les candidatures aux nouveaux gTLD sont en cours d'évaluation pour la 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 soucis 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 sont les documents importants que le Conseil a révisé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], 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 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.

    2. Demande de budget du SSAC

      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.

      Justification de la résolution 2013.05.18.12

      Les procédures acé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 dans la procédure d'application 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 ne crée 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.

  3. Session exécutive :

    1. Prime de risque du PDG

      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.

      Fondements de la résolution 2013.05.18.13 – 2013.05.18.14

      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.

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

      Fondements 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]

resolutions-18may13-fr.pdf  [244 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."