Glossaire
Le glossaire ci-après définit les termes et fournit, le cas échéant, les acronymes couramment utilisés dans le Guide de candidature. Pour en faciliter la consultation, les entrées sont présentées par ordre alphabétique. Il convient de noter que la liste des termes n’est pas exhaustive.
Tableau G1 Glossaire
| Terme | Acronyme | Définition |
|---|---|---|
| Série 2012 | Série de candidatures du programme des nouveaux gTLD lancée en 2012. | |
| Série 2026 | Série de candidatures du programme des nouveaux gTLD lancée en avril 2026 et faisant l’objet de ce Guide de candidature. | |
| Étiquette A | Une « étiquette A » est la forme compatible avec ASCII (ACE) d’une chaîne IDN. Les étiquettes A comportent le préfixe "xn--", suivi par une chaîne qui constitue un résultat valide de l’algorithme Punycode [RFC3492], avec une longueur maximale de 59 caractères ASCII. | |
| Mécanismes de responsabilité | Mécanismes établis dans les statuts constitutifs de l’ICANN permettant la révision et le réexamen des actions de l’ICANN (voir la Section 2.7 Mécanismes de responsabilité). Ces mécanismes sont les suivants : la Communauté habilitée, le Réexamen, le Processus de révision indépendante, et l’Ombudsman. | |
| Contrôle administratif et préparation pour le « jour du dévoilement » | Processus manuel destiné à mettre en place des diligences raisonnables de nature administrative (voir la Section 3.2 Contrôle administratif et préparation pour le jour du dévoilement) et à vérifier si les frais d’évaluation ont été réglés, pendant que l’ICANN se prépare pour le jour du dévoilement (voir la Section 3.4 Jour du dévoilement). | |
| Avis | Contribution adressée par un comité consultatif au Conseil d’administration de l’ICANN. | |
| Comité consultatif | AC | Organisme formellement reconnu par les statuts constitutifs de l’ICANN1, chargé de conseiller le Conseil d’administration de l’ICANN sur les politiques relevant de la compétence et de la mission de l’ICANN. Les quatre AC de l’ICANN sont : le Comité consultatif At-Large, le Comité consultatif gouvernemental, le Comité consultatif du système des serveurs racine et le Comité consultatif sur la sécurité et la stabilité. |
| Affirmations | Les affirmations du rapport final SubPro2 concernent des conclusions du groupe de travail selon lesquelles un élément de la série 2012 du programme des nouveaux gTLD demeure approprié, ou du moins acceptable, pour des séries ultérieures. | |
| Affirmations avec modifications | Dans le rapport final SubPro, similaires à des affirmations mais utilisées lorsque le groupe de travail recommande un ajustement mineur aux politiques ou à la mise en œuvre de la série 2012 du programme des nouveaux gTLD. | |
| Code standard américain pour l’échange d’information | ASCII | Norme d’encodage de caractères permettant de représenter un jeu spécifique de 95 caractères imprimables (axés sur l’anglais) et 33 caractères de contrôle, pour un total de 128 points de code. |
| Procédure d’appel | Appel | Mécanisme permettant aux parties concernées de faire appel d’une décision rendue par un panel d’objection. Voir la Section 4.5.9.1 Déposer un recours. |
| Candidat | Entité qui dépose auprès de l’ICANN une candidature pour un nouveau gTLD pendant la période de dépôt de candidatures. | |
| Évaluation du candidat | Processus entamé a) une fois que la chaîne a été évaluée et n’a pas été incluse dans un ensemble conflictuel, ou b) une fois que la chaîne a été évaluée et a prévalu au sein d’un ensemble conflictuel. Il est mené parallèlement à l’évaluation de la candidature (voir le Module 7 Procédures d’évaluation de chaînes et de candidatures, en fonction du numéro de priorité de la candidature, à moins que d’autres processus n’empêchent la poursuite de celle-ci. L’évaluation du candidat comporte deux volets obligatoires : la vérification d’antécédents et l’évaluation financière et opérationnelle. Se reporter à la Section 6.1 Vérification d’antécédents et à la Section 6.2 Évaluation financière et opérationnelle. | |
| Guide de candidature | AGB | Le Guide de candidature aux gTLD qui décrit les exigences régissant le dépôt de candidature et les processus d’évaluation. |
| Programme de soutien aux candidats | ASP | Programme distinct du processus de candidature aux gTLD, offrant une réduction des frais liés au programme des nouveaux gTLD de l’ICANN aux candidats remplissant des critères de besoin financier. Se reporter à l’Annexe 11 Programme de soutien aux candidats. |
| Candidature | Dossier de candidature à un nouveau gTLD, soumis conformément aux conditions générales établies dans le Guide de candidature. Il inclut les réponses aux questions du dossier de candidature, les pièces justificatives et toute autre information demandée au candidat par l’ICANN. Se reporter à l’Annexe 1 Questions du dossier de candidature. | |
| Demande de modification au dossier de candidature | ACR | Procédure intervenant en réponse à une objection et permettant à un candidat de solliciter la modification de son dossier (par exemple, pour ajouter ou modifier un engagement volontaire des opérateurs de registre ou une politique d’enregistrement communautaire), via une demande de modification du dossier de candidature. Voir la Section 3.8 Demande de modification de dossier de candidature. |
| Évaluation de candidature | L’évaluation d’une candidature comporte les vérifications suivantes : vérification du fournisseur de services de registre, examen des noms géographiques, examen des noms réservés, évaluation du plan d’atténuation des collisions de noms, évaluation des exemptions au Code de conduite, évaluation des engagements des opérateurs de registre (et notamment l’évaluation des politiques d’enregistrement communautaire), évaluation de l’admissibilité au statut de TLD de marque et évaluation des variantes de chaîne. Parmi ces évaluations, seule la vérification du fournisseur de services de registre est obligatoire. Voir le Module 7 Procédures d’évaluation de chaînes et de candidatures. | |
| Priorité de la candidature | Numéro attribué à chaque candidature lors d’un tirage au sort (se reporter à la Section 3.7 Ordre de traitement des candidatures et tirage au sort pour l’établissement des priorités de traitement). qui établit l’ordre de traitement des candidatures pour la série en cours. | |
| Questions du dossier de candidature | L’ensemble des questions auxquelles les candidats doivent répondre. Lors de la série 2012, ces questions étaient fournies en pièce jointe au module 2 du Guide de candidature. Se reporter à l’Annexe 1 Questions du dossier de candidature. | |
| Série de candidatures | Cycle complet de traitement des candidatures reçues au cours d’une même période de dépôt de candidatures. Les conditions générales du Guide de candidature s’appliquent à une seule série de candidatures (voir l’Annexe 10 Conditions générales). Les séries ultérieures feront l’objet d’une mise à jour des informations du Guide (voir la Section 2.8 Séries ultérieures de candidatures). | |
| Période de dépôt de candidatures | La fenêtre de temps pendant laquelle les candidatures peuvent être créées et déposées. Voir la Section 3.1 Demande de modification de dossier de candidature. | |
| Système de candidature | Système sécurisé permettant aux candidats de soumettre les informations requises pour déposer une demande à une ou plusieurs composantes du programme des nouveaux gTLD, qu’il s’agisse du programme de soutien aux candidats, de la préévaluation des fournisseurs de services de registre, ou de la candidature à un gTLD. Voir le Système de gestion des candidatures aux TLD (TAMS). | |
| Chaîne faisant l’objet d’une candidature à un gTLD | Chaîne sur laquelle porte une candidature à un gTLD. | |
| Vérification d’antécédents | Procédure visant à protéger l’intérêt public lors de l’allocation des ressources critiques de l’Internet, en veillant à ce que seuls des organismes, institutions ou sociétés dûment établis et en règle soient autorisés à exploiter un nouveau gTLD. Voir la Section 6.1 Vérification d’antécédents . | |
| Contrat de registre de base | RA de base | Formulaire de contrat de registre que l’ICANN et les candidats aux gTLD retenus signent avant toute délégation d’un nouveau gTLD. Il décrit les obligations opérationnelles, techniques et de toute autre nature régissant l’exploitation d’un gTLD par un opérateur de registre, ainsi que les droits et responsabilités correspondantes de l’ICANN. Une ou plusieurs spécifications peuvent être ajoutées au contrat de registre de base en fonction des résultats de l’évaluation et des circonstances individuelles de chaque gTLD. Le contrat de registre de base est le résultat d’une vaste consultation menée auprès de la communauté. L’ICANN n’envisagera de modifier le contrat que dans des circonstances extraordinaires, telles que des problèmes juridiques, juridictionnels ou réglementaires uniques qui empêcheraient légalement une entité d’exécuter le contrat de registre de base tel quel. |
| Noms bloqués | Certaines chaînes et leurs variantes allouables qui, conformément à la politique en vigueur, ne sont éligibles ni au dépôt de candidature ni à la délégation lors de toute série future de gTLD. Les noms bloqués ne peuvent faire l’objet d’aucune procédure d’exception et ne peuvent être demandés par aucune entité. Voir la Section 7.2.1 Noms réservés. | |
| Identification des noms bloqués | Lorsque le candidat saisit le nom de la chaîne faisant l’objet de sa candidature, le système vérifie automatiquement si cette chaîne, ainsi que ses variantes, correspondent à un nom bloqué. | |
| TLD de marque | Désignation faisant référence à un TLD exploité par et pour une entité sous son nom de marque déposée, conformément au contrat de registre passé entre l’entité et l’ICANN. Voir la Section 7.7 Évaluation de l’admissibilité au statut de TLD de marque et l’Annexe 4 Contrat de registre de base. Pour qu’un TLD soit désigné comme un TLD de marque, un opérateur de registre doit en faire la demande et la marque déposée doit être enregistrée au Centre d’échange d’information sur les marques. | |
| Évaluation de l’admissibilité au statut de TLD de marque | Procédure visant à confirmer que le candidat satisfait aux critères d’admissibilité à la désignation « TLD de marque ». Une désignation aboutie entraîne l’ajout de la spécification 13 au contrat de registre de base du candidat, sous réserve de la réussite de toutes les étapes de l’évaluation. Se reporter à la Section 7.3 Évaluation d’admissibilité au statut de TLD de marque. | |
| Rapport final de la CCT | Le Rapport final de la révision de la concurrence, de la confiance et du choix du consommateur3 (CCT), du 8 septembre 2018. | |
| Question de clarification | CQ | Demande de précisions adressée à un candidat par un panel d’évaluation pour obtenir des compléments d’information. Se reporter à la Section 1.2.12 Questions de clarification. |
| Générique fermé | Selon le rapport final du groupe de travail consacré au processus d’élaboration de politiques sur les procédures pour des séries ultérieures (SubPro), un générique fermé est « un TLD représentant une chaîne qui correspond à un nom ou à un terme générique, sous lequel les noms de domaines sont enregistrés et utilisés exclusivement par l’opérateur de registre ou ses affiliés ». Se reporter à la Section 3.1.7 Chaînes à usage exclusif (génériques fermés) | |
| Évaluation d’éligibilité à une exemption au Code de conduite | Si un candidat propose d’enregistrer l’ensemble des noms de domaine du gTLD exclusivement pour l’usage de l’opérateur de registre ou celui de ses affiliés et souhaite renoncer aux protections normalement applicables à lui-même et à ses affiliés, l’ICANN peut accorder une exemption au Code de conduite (spécification 9 du contrat de registre de base), à condition que le gTLD ne soit pas une chaîne générique et que l’opérateur de registre remplisse les critères d’éligibilité à l’exemption. Voir la Section 7.4 Évaluation d’éligibilité à une exemption au Code de conduite. | |
| Liste des chaînes en collision | Liste des chaînes présentant un risque élevé de collision de noms (voir Section 7.7 Collision de noms). Cette liste est établie et tenue à jour par l’ICANN. | |
| Communauté | L’ICANN adhère à un modèle multipartite où les individus, les groupes des représentants des entités non commerciales, le secteur et les gouvernements, collectivement la « communauté de l’ICANN », jouent un rôle important dans une optique d’approche communautaire et consensuelle d’élaboration des politiques. | |
| Candidatures communautaires | Candidature à une chaîne de gTLD destinée à être exploitée au profit d’une communauté clairement délimitée. Se reporter à la Section 5.4 Évaluation de la priorité communautaire. La désignation d’une candidature comme étant communautaire relève de l’entière discrétion du candidat. Ce dernier doit toutefois pouvoir justifier de sa légitimité en tant que représentant de la communauté évoquée dans sa candidature. | |
| Objection de la communauté | Objection déposée au motif qu’une opposition substantielle à une candidature à un gTLD émane d’une part significative de la communauté à laquelle la chaîne de gTLD peut être explicitement ou implicitement destinée. Se reporter à la Section 4.5.10.4. Principes : communauté | |
| Évaluation de la priorité communautaire | CPE | Processus optionnel de résolution des conflits de chaînes, réservé aux candidats communautaires. Se reporter à la Section 5.4 Évaluation de la priorité communautaire. |
| Politiques d’enregistrement communautaire | Les politiques d’enregistrement communautaire figurant dans un contrat de registre (« politiques d’enregistrement communautaire ») sont un ensemble de politiques qu’une candidature à un TLD communautaire doit intégrer au contrat de registre applicable Voir la Section 7.8.4. Politiques d’enregistrement communautaire. Elles fixent, a minima, les critères d’admissibilité pour l’enregistrement au gTLD faisant l’objet d’une candidature et les conditions d’acceptation des enregistrements de second niveau par le registre. Les opérateurs de gTLD communautaires peuvent avoir des politiques d’enregistrement additionnelles en-dehors du contrat de registre, pour autant que celles-ci ne contreviennent pas aux exigences stipulées dans les contrats et les politiques en vigueur de l’ICANN. | |
| Évaluation des politiques d’enregistrement communautaire | L’inclusion des politiques d’enregistrement communautaires proposées dans la spécification 12 d’un contrat de registre de base est subordonnée à leur évaluation et à leur approbation préalables par l’ICANN. Voir la Section 7.8.4 Politiques d’enregistrement communautaire. | |
| gTLD communautaire | Un gTLD communautaire est un gTLD exploités au profit d’une communauté clairement définie. | |
| Politique de consensus | Politique créée à travers le processus d’élaboration de politiques de la GNSO prévu à l’Annexe A des statuts constitutifs de l’ICANN4. Une liste des politiques de consensus en vigueur est disponible sur le site Web des parties contractantes5. | |
| Conflit | Situation où plusieurs candidatures portent sur des chaînes identiques ou similaires. Reportez-vous à la Section 5.2 Conflits de chaînes et procédures de résolution. | |
| Ensemble conflictuel | Ensemble de candidatures constitué lorsque des chaînes faisant l’objet d’une candidature à un nouveau gTLD sont jugées identiques ou similaires, que ce soit au terme de l’évaluation de la similarité ou par suite d’une objection relative à des chaînes prêtant à confusion. | |
| Interruption contrôlée | Période obligatoire d’au moins 90 jours suivant la délégation d’un gTLD, pendant laquelle le registre doit fournir une réponse spécifique à toute requête pour informer les utilisateurs qu’une collision de noms s’est produite. Se reporter à la Section 7.7 Collision de noms. | |
| Domaine de premier niveau géographique | ccTLD | Désigne la catégorie de domaines de premier niveau réservés pour être utilisés par les pays, territoires et régions géographiques conformément à la liste des codes de pays de la norme ISO 3166-1. Voir la base de données de la zone racine6. |
| Délégation | Processus consistant à modifier la zone racine pour y ajouter un nouveau TLD et à confier la gestion des enregistrements des noms domaine de ce TLD à l’opérateur de registre correspondant. | |
| Fournisseur de services de règlement de litiges | DRSP | Entité approuvée par l’ICANN pour rendre des décisions dans le cadre de procédures de règlement de litiges faisant suite à des objections. Se reporter à la Section 4.5.3 Fournisseurs de services de règlement de litiges. |
| Vérification de la stabilité du DNS | Vérification automatisée visant à analyser toute chaîne faisant l’objet d’une candidature, et ses variantes. Voir la Section 3.1.8.3 Examen de la stabilité du DNS. afin de garantir la conformité des chaînes aux normes techniques en vigueur (normes DNS et noms d’hôte, protocole IDNA 2008 pour les IDN, et RZ-LGR). En cas de non-conformité, le candidat en est averti et peut demander une révision de l’évaluation automatisée. | |
| Nom de domaine | Chaîne de caractères unique constituée de deux niveaux ou plus (exemple : jean.dupont.nom), maintenue dans la base de données d’un registre. | |
| Système des noms de domaine | DNS | Système hiérarchique mondial des noms de domaine. |
| Extensions de sécurité du système des noms de domaine | DNSSEC | Protocole qui sécurise la recherche des noms de domaine sur Internet en intégrant une chaîne de signatures numériques à la hiérarchie du DNS. |
| Contestation d’une évaluation | Mécanisme qui autorise un candidat à contester certains résultats d’évaluation en invoquant une erreur systémique, factuelle ou de procédure. | |
| Panel d’évaluation | Groupe d’experts spécialisés dans le domaine examiné (par exemple, le panel d’évaluation de la similarité des chaînes). Il utilise des critères établis par la communauté pour évaluer la conformité d’un candidat aux exigences applicables. | |
| TLD existant | Chaîne qui figure dans la liste de la base de données de la zone racine7. | |
| Évaluation approfondie | EE | Processus accordant aux candidats un délai supplémentaire pour réussir les évaluations commencées lors de la phase initiale. Cette seconde phase d’évaluation est applicable aux candidatures rejetées lors de l’évaluation initiale, mais jugées admissibles à un examen complémentaire. Se reporter à la Section 1.2.14.1 Évaluation approfondie. |
| Protocole d’avitaillement extensible | EPP | Protocole utilisé pour les communications électroniques entre un bureau d’enregistrement et un registre en vue de la mise à disposition de noms de domaine. |
| Ensemble conflictuel final | Groupe de candidatures regroupées dans un ensemble conflictuel à l’issue de l’évaluation de la similarité des chaînes. Se reporter à la Section 7.10 Évaluation de la similarité de chaînes. | |
| Rapport final du processus d’élaboration de politiques consacré aux procédures pour des séries ultérieures de nouveaux gTLD | Rapport final SubPro | Rapport final8 sur le processus d’élaboration de politiques relatif aux procédures pour des séries ultérieures de nouveaux gTLD, en date du 20 janvier 2021. |
| Ensemble conflictuel finalisé | Un ensemble conflictuel est dit « finalisé » lorsqu’il satisfait à l’ensemble des critères d’admissibilité aux enchères ci-après :
|
|
| Évaluation financière et opérationnelle | Évaluation visant à déterminer si un candidat possède la capacité financière et opérationnelle requise pour assurer la pérennité du registre et s’il a mis en œuvre des garanties suffisantes pour pérenniser ses activités commerciales et lutter contre l’utilisation malveillante. Se reporter à la Section 6.2 Évaluation financière et opérationnelle. | |
| Futures séries | Le programme des nouveaux gTLD traite les candidatures par séries. L’expression « futures séries » (ou « séries ultérieures de candidatures ») renvoie à toutes les séries qui suivront celle de 2026. Voir la Section 2.8 Séries ultérieures de candidatures. | |
| Avis du GAC concernant les nouveaux gTLD | Avis que le GAC soumet au Conseil d’administration de l’ICANN au sujet d’une ou de plusieurs candidatures à des gTLD. Voir la Section 4.3 Avis de consensus du GAC. | |
| Alerte précoce d’un membre du GAC | Avis émis par le GAC au sujet d’une candidature à un gTLD pour signaler qu’un ou plusieurs gouvernements la jugent potentiellement sensible ou problématique. Voir la Section 4.2 Alertes précoces émanant des membres du GAC. | |
| Organisation de soutien aux extensions génériques | GNSO | Organe de l’ICANN chargé de l’élaboration des politiques9 relatives aux gTLD. La GNSO a formulé les recommandations de politiques en vue de l’introduction de nouveaux gTLD. |
| Domaine générique de premier niveau | gTLD | Désigne la classe de domaines de premier niveau (TLD) qui comprend des domaines d’usage général tels que .com, .net, .edu et .org. Cette classe comprend également des domaines associés au programme des nouveaux gTLD, tels que .futbol, .istanbul et .pizza, ainsi que des noms dans d’autres langues et alphabets. L’ICANN coordonne l’élaboration des règles et des politiques qui encadrent l’enregistrement des noms de domaine dans les gTLD. |
| Nom géographique | Un nom de domaine générique de premier niveau et ses variantes allouables est considéré un nom géographique s’il remplit un des critères ci-après : être le nom (en quelque langue que ce soit) d’une ville capitale d’un pays ou territoire répertorié par la norme ISO 3166-1 ; être le nom d’une ville ou d’une région que le candidat déclare vouloir associer à l’usage de ce gTLD ; correspondre à l’identique à une subdivision administrative (comté, province, État, etc.) répertoriée par la norme ISO 3166-2, ou à une appellation figurant sur la liste des régions de l’UNESCO10 ou dans la classification M49 de l’ONU11. Des conditions de qualification spécifiques s’appliquent à chaque catégorie. Se reporter à la Section 7.5 Noms géographiques. | |
| Identification des noms géographiques | Dans le cadre de l’identification des noms géographiques, un panel examine l’ensemble des chaînes faisant l’objet de candidatures afin de déterminer celles qui peuvent être qualifiées de noms géographiques, comme décrit dans la Section 7.5 Noms géographiques. Cette étape se distingue du processus de vérification de fond que constitue l’examen des noms géographiques (Section 7.5.3.2), qui intervient pendant l’évaluation de la candidature. | |
| Panel de noms géographiques | GNP | Un panel d’experts mandaté par l’ICANN pour examiner des chaînes faisant l’objet d’une candidature à un TLD, identifier celles qui constituent des noms géographiques, et vérifier la documentation requise. |
| Examen des noms géographiques | Vérification et examen de fond des réponses fournies dans la candidature pour les chaînes jugées géographiques. Cet examen fait partie de l’évaluation de la candidature. Voir la Section 7.5.3.2 Examen des noms géographiques. | |
| Comité consultatif gouvernemental | GAC | Le GAC porte la voix des gouvernements et des organisations intergouvernementales (OIG) au sein de la structure multipartite de l’ICANN. Créé en vertu des statuts constitutifs de l’ICANN, il agit en tant que comité consultatif auprès du Conseil d’administration. Sa fonction principale consiste à donner des avis à l’ICANN sur des dossiers de politique publique, en particulier lorsqu’il pourrait exister une interaction entre les activités ou les politiques de l’ICANN et des lois nationales ou des accords internationaux. |
| Frais de candidature à un gTLD | Frais que doit acquitter chaque candidat pour que sa candidature soit examinée. Ils peuvent comprendre un acompte et le règlement du solde pour chaque candidature déposée. | |
| Plan d’atténuation des risques élevés | La Section 7.7.5 Évaluation du plan d’atténuation de risques élevés de collision de noms détaille les mesures préventives et correctives spécifiques que le candidat mettra en œuvre pour atténuer le risque de collision de noms, y compris les communications destinées aux utilisateurs finaux concernés. Chaque mesure d’atténuation doit s’inscrire dans un calendrier de mise en œuvre précis. La durée totale ne doit pas dépasser deux ans. | |
| Enchères de l’ICANN | Enchères organisées par l’ICANN en application des procédures relatives aux conflits de chaîne. | |
| Conseil d’administration de l’ICANN | Organe qui examine les recommandations de politiques élaborées par la communauté de l’ICANN et transmet les politiques approuvées à l’organisation ICANN pour leur mise en œuvre. Le Conseil d’administration12 exerce également une supervision stratégique sur l’organisation ICANN, en veillant à ce qu’elle agisse dans le cadre de sa mission, de manière efficace, efficiente et éthique. | |
| Communauté de l’ICANN | « La Communauté » | L’ICANN adhère à un modèle multipartite où les individus, les groupes des représentants des entités non commerciales, le secteur, et les gouvernements, collectivement la « communauté de l’ICANN », jouent un rôle important dans une optique d’approche communautaire et consensuelle de l’élaboration des politiques. |
| Organisation ICANN | org/ICANN org | Entité13 chargée de mettre en œuvre les recommandations de la communauté de l’ICANN, sous la direction du Conseil d’administration. |
| Bureau d’enregistrement accrédité par l’ICANN | Entité ayant conclu un contrat d’accréditation de bureau d’enregistrement14 avec l’ICANN. Le bureau d’enregistrement est habilité à modifier un registre par l’ajout, la suppression ou la mise à jour d’enregistrements de noms de domaine. | |
| Orientations relatives à la mise en œuvre | IG | L’un des types de conclusions du Rapport final SubPro. En l’occurrence, il s’agit d’une action que le groupe de travail recommande fortement en partant du principe qu’elle sera mise en œuvre tout en reconnaissant que des raisons valables peuvent, dans certaines circonstances, justifier de ne pas suivre la recommandation à la lettre. Il incombe néanmoins à la partie visée par la recommandation de faire de son mieux pour en atteindre l’objectif fondamental (énoncé dans la justification et la recommandation connexes, le cas échéant), quitte à emprunter une autre voie. En tout état de cause, toutes les répercussions de l’emprunt d’une autre voie doivent être mesurées et soupesées avant d’écarter la voie recommandée. Les orientations relatives à la mise en œuvre précisent généralement les modalités d’application d’une recommandation. L’emploi du conditionnel (« devrait/devraient ») y signifie que le groupe de travail anticipe la mise en œuvre, sous réserve des mises en garde susmentionnées. |
| Équipe de révision de la mise en œuvre | IRT | Équipe de volontaires de la communauté de l’ICANN, chargée d’examiner les plans de mise en œuvre élaborés par l’organisation ICANN, de s’assurer de leur conformité avec les recommandations de la GNSO qui ont été approuvées par le Conseil d’administration de l’ICANN, de fournir des réponses à l’organisation ICANN et de lui demander des clarifications au besoin. Elle émet également des avis sur les aspects techniques et opérationnels desdites recommandations. |
| Objecteur indépendant | IO | Partie mandatée par l’ICANN pour agir au seul nom de l’intérêt public. L’objecteur indépendant (voir la Section 4.5.4 Objecteur indépendant) peut déposer des objections contre des candidatures en invoquant des motifs d’intérêt public limité (voir Section 4.5.1.3 Motif d’objection : intérêt public limité) et d’opposition communautaire (voir Section 4.5.1.4 Motif d’objection : opposition communautaire). |
| OIG - Organisation intergouvernementale | OIG | Organisation composée principalement d’États souverains ou d’autres entités intergouvernementales. Une OIG est créée par un traité ou tout autre accord qui lui sert de charte constitutive. On citera, à titre d’exemple, l’Organisation des Nations Unies, la Banque mondiale ou encore l’Union européenne. |
| Nom de domaine internationalisé | IDN | Nom de domaine dont une ou plusieurs chaînes contiennent des caractères autres que des lettres ASCII, des chiffres ou des traits d’union. Étant donné que les IDN permettent l’utilisation de caractères Unicode, ils peuvent inclure des caractères de langues et de scripts locaux. Par exemple, 실례.테스트 est un nom de domaine composé entièrement de caractères hangeul. |
| Autorité chargée de la gestion de l’adressage sur Internet | IANA | Ensemble de fonctions de coordination de l’Internet visant à garantir l’affectation des paramètres de protocole uniques au niveau mondial. Elles comprennent la gestion de la zone racine du DNS et de l’espace d’adresses de protocole Internet. Les fonctions IANA sont exécutées par l’entité Identificateurs techniques publics, société affiliée à l’ICANN. |
| Objection pour atteinte aux droits d’autrui | Objection déposée au motif que la chaîne faisant l’objet d’une candidature à un gTLD porte atteinte aux droits existants de l’objecteur. Voir la Section 4.5.1.2 Motif d’objection : atteinte aux droits d’autrui. | |
| Objection relevant de l’intérêt public limité | Objection déposée au motif que la chaîne faisant l’objet d’une candidature à un gTLD est contraire aux règles de morale et d’ordre public généralement admises et reconnues par les principes du droit international. Voir la Section 4.5.1.3 Motif d’objection : intérêt public limité | |
| Fournisseur principal de services de registre | RSP principal | Le fournisseur principal de services de registre assure au minimum la fourniture du protocole d’avitaillement extensible et des services d’annuaire de données d’enregistrement. Il génère également les dépôts d’entiercement de données et les transmet à l’agent d’entiercement de données agréé pour le gTLD. |
| Engagements d’intérêt public obligatoires | PIC obligatoires | Les engagements d’intérêt public obligatoires (voir la Section 7.8.1 Engagements d’intérêt public obligatoires) sont des règles ou directives que l’ICANN impose à l’opérateur d’un registre de gTLD afin de protéger l’intérêt public et les droits des consommateurs. La mise en œuvre des PIC obligatoires répond souvent à des préoccupations soulevées par le GAC. |
| Projet d’analyse de la collision de noms | NCAP | En 2017, le Conseil d’administration a mandaté le SSAC pour lancer le projet NCAP afin d’étudier les collisions de noms. Le terme « collision de noms » désigne une situation dans laquelle un nom, défini et utilisé au sein d’un espace de noms, apparaît également dans un autre. Il peut en résulter un comportement inattendu si des utilisateurs ou des applications, pensant utiliser un nom dans un espace de noms donné, l’utilisent en réalité dans un autre où sa finalité diffère. Une collision de noms peut être d’origine accidentelle ou malveillante. |
| Évaluation du plan d’atténuation de risques élevés de collision de noms | Le candidat à une chaîne jugée à haut risque de collision par l’ICANN et dont la situation dans un ensemble conflictuel a été résolue peut soumettre un plan d’atténuation de risques élevés de collision de noms pour examen par des experts techniques. Voir la Section 7.7.5 Évaluation du plan d’atténuation de risques élevés de collision de noms | |
| Évaluation initiale des collisions de noms | Cette évaluation initiale des collisions de noms a pour but de recenser les chaînes qui présentent un risque élevé de collision de noms comme décrit dans « Collision de noms ». Se reporter à la Section 7.7.2 Évaluation initiale des collisions de noms. Si un risque élevé est avéré pour une chaîne, le candidat peut soumettre un plan d’atténuation qui, approuvé après évaluation, permettra à la candidature de poursuivre son cours. | |
| Portail des services de nommage | NSp | Service en ligne disponible sur le site Web de l’ICANN, qui offre aux parties contractantes (par exemple, des opérateurs de registre sous contrat et des bureaux d’enregistrement accrédités) un guichet unique pour gérer leurs activités avec l’organisation ICANN. Le portail, qui permet de rationaliser les processus opérationnels, est personnalisé avec des fonctionnalités demandées par la communauté, à savoir : suivi des dossiers, accès ouvert à plusieurs utilisateurs d’une même société et flux de travail structurés. Les utilisateurs peuvent poser des questions, soumettre des informations et demander des autorisations via le portail. |
| Système de nommage | Voir le RFC 9499, section 2 : https://www.rfc-editor.org/rfc/rfc9499.html#name-names. | |
| Objection | Objection déposée auprès d’un fournisseur de services de règlement de litiges conformément aux procédures de ce fournisseur. Se reporter à la Section 4.5 Objections et recours. | |
| Objecteur | Personne ou entité ayant déposé une objection contre une candidature à un nouveau gTLD auprès du DRSP approprié. | |
| Dossier du compte de l’organisation | Informations sur l’organisation collectées pendant l’étape préalable au dépôt de candidature : informations sur le candidat, coordonnées des contacts principal et secondaire et la preuve de la constitution légale, entre autres. Pour en savoir plus sur le dossier du compte de l’organisation, se reporter au Questionnaire 4 : antécédents et organisation de l’entité candidate, figurant à l’Annexe 1 Questions du dossier de candidature. |
|
| Produits | Affirmations, recommandations de politique et orientations relatives à la mise en œuvre, issues du Rapport final. | |
| Données personnelles identifiables | PII | Toute représentation d’informations permettant de déduire l’identité de la personne physique à laquelle elles se rapportent. |
| Validation des chaînes préalable au dépôt de candidature | Validations des chaînes principales et de leurs variantes, ainsi que des chaînes de remplacement, automatiquement intégrées et appliquées par le TAMS. Voir la Section 3.1.8 Validation des chaînes préalable au dépôt de candidature. | |
| Ensemble conflictuel préliminaire | Ensemble dans lequel sont placées, le jour du dévoilement (voir la Section 3.4 Jour du dévoilement), toutes les candidatures qui portent sur des chaînes identiques. | |
| Rapport de révision de la mise en œuvre du programme | PIRR | Rapport publié en 2016 par l’organisation ICANN regroupant les retours d’expérience de son personnel sur la mise en œuvre opérationnelle de la série 2012 du programme des nouveaux gTLD.15 |
| Procédure de règlement de litiges relatifs aux engagements d’intérêt public | PICDRP | Mécanisme de règlement des litiges qui fait appel, dans certains cas, à un panel d’évaluation. Pour les gTLD dont les contrats de registre prévoient le PICDRP, la procédure est ouverte à toute partie lésée du fait du non-respect par un opérateur de registre de ses PIC. Les PIC et le PICDRP sont des mécanismes de protection de la communauté créés dans le cadre de la série 2012 du programme des nouveaux gTLD. |
| Engagements d’intérêt public | PIC | Obligations contraignantes qui lient les opérateurs de registre de gTLD à la communauté de l’Internet, en vertu de leurs contrats avec l’organisation ICANN. Le respect des PIC fait l’objet d’une supervision et de mesures d’application par l’organisation ICANN. (Voir aussi PICDRP et RVC) |
| Bureaux d’enregistrement | Rr | Organisation à travers laquelle des individus et des entités (titulaires de nom de domaine) enregistrent des noms de domaine. Au cours du processus d’enregistrement, un bureau d’enregistrement vérifie que le nom de domaine demandé remplit les exigences applicables et soumet le nom à l’opérateur de registre approprié. Les bureaux d’enregistrement sont également responsables de collecter l’information requise concernant les titulaires de nom de domaine et de rendre ces informations disponibles à travers le RDDS. |
| Procédure de règlement de litiges relatifs à des restrictions à l’enregistrement | RRDRP | Procédure formelle qui offre à des institutions établies un moyen de régler des litiges liés à des restrictions à l’enregistrement figurant dans le contrat de registre d’un gTLD. |
| Registre | Ry | La base de données principale faisant autorité et regroupant tous les noms de domaine enregistrés dans chaque domaine de premier niveau. L’opérateur du registre conserve la base de données principale et génère le fichier de zone permettant aux ordinateurs d’acheminer le trafic Internet à partir de, et vers les domaines de premier niveau partout dans le monde. |
| Contrat de registre | RA | Contrat conclu entre l’ICANN et l’opérateur de registre d’un gTLD désigné, où sont définis les droits, les obligations et les dispositions régissant l’exploitation du gTLD par l’opérateur de registre. Voir l’Annexe 4 Contrat de registre de base. |
| Évaluation des engagements d’un opérateur de registre | RCE | Chaque RVC ou politique d’enregistrement communautaire qu’un opérateur de registre propose d’inclure dans le contrat de registre applicable fait l’objet de cette évaluation par l’ICANN, qui détermine si ledit opérateur de registre satisfait à tous les critères énoncés dans le présent Guide de candidature. Se reporter à la Section 7.8.3.2 Évaluation des engagements de l’opérateur de registre. |
| Opérateur de registre | RO | Organisation qui tient à jour la base de données principale (registre) de tous les noms de domaine enregistrés dans un TLD donné. Les opérateurs de registre reçoivent des demandes des bureaux d’enregistrement pour ajouter, supprimer ou modifier des noms de domaine et effectuent les changements correspondants dans le registre. Les opérateurs de registre gèrent également les serveurs de noms TLD faisant autorité et créent le fichier de zone. Cette information permet aux serveurs de noms récursifs sur Internet de traduire les noms de domaine en adresses de protocole Internet, et permet ainsi aux appareils connectés à Internet de communiquer entre eux. |
| Fournisseur de services de registre | RSP | Entité qui fournit certaines opérations techniques à un opérateur de registre. |
| Programme d’évaluation des fournisseurs de service de registre (RSP) | Programme permettant aux fournisseurs de services de registre de faire évaluer en une seule fois les services qu’ils entendent proposer aux candidats. Les fournisseurs retenus sont ensuite préapprouvés pour la série 2026. Les candidats à un gTLD qui intègrent un RSP préapprouvé dans leur dossier de candidature sont dispensés d’évaluation technique, tant que ledit RSP conserve sa préapprobation. | |
| Politique d’évaluation des services de registre | RSEP | Politique qui régit l’évaluation des services de registre proposés par un opérateur de registre ou un candidat. |
| Panel d’évaluation technique des services de registre | RSTEP | Groupe d’experts consacré à la conception, gestion et mise en place des systèmes complexes et protocoles de normes utilisés dans l’infrastructure Internet et DNS. Les membres du RSTEP sont sélectionnés par son président. Tous les membres du RSTEP et le président ont conclu un accord établissant que le panel sera neutre et agira conformément aux définitions spécifiées concernant la sécurité et la stabilité. |
| Engagements volontaires d’un opérateur de registre | RVC | Engagements généralement facultatifs qu’un candidat peut proposer pour répondre aux préoccupations de tiers concernant la chaîne gTLD faisant l’objet de sa candidature, ou pour promouvoir l’intérêt public, la confiance de la communauté ou des garanties supplémentaires quant à l’exploitation du gTLD. Une fois approuvés par l’ICANN à l’issue de l’évaluation des engagements de l’opérateur de registre (RCE), ils sont voués à être intégrés dans la spécification 11 du contrat de registre de base à titre d’obligations contractuelles. |
| Noms réservés | Certaines chaînes, ainsi que leurs variantes allouables, qui ne peuvent généralement pas faire l’objet d’un enregistrement car elles sont mises à la disposition exclusive d’entités spécifiques. Les noms réservés comprennent ceux associés à certaines organisations internationales et intergouvernementales (OIG et OING internationales à représentation limitée). Seule l’entité concernée peut demander l’attribution de ces noms par le biais d’une procédure dérogatoire, qui requiert la présentation des pièces justificatives prévues par les procédures applicables. | |
| Identification des noms réservés | Lorsque le candidat saisit le nom de la chaîne faisant l’objet de sa candidature, le système vérifie automatiquement si cette chaîne, ainsi que ses variantes, apparaissent dans la liste de noms bloqués. Voir la Section 7.2.2.2 Identification des noms réservés. | |
| Identification des noms réservés | La procédure de vérification de noms réservés détermine si la chaîne réservée a été demandée par l’organisation habilitée et vérifie les pièces justificatives, comme le prévoit la section Noms réservés . Voir la Section 7.2.2.3 Examen des noms géographiques. | |
| Mécanisme de protection de droits | RPM | Dispositif contribuant à la protection des droits de propriété intellectuelle au sein du système des noms de domaine. Les RPM comprennent la politique de règlement uniforme de litiges relatifs aux noms de domaine, le système uniforme de suspension rapide et les procédures de règlement de litiges après délégation relatifs à des marques déposées. |
| Zone racine | La base de données de la zone racine représente les détails de délégation des domaines de premier niveau, gTLD et ccTLD compris. En tant que gestionnaire de la zone racine du DNS, l’IANA est responsable de la coordination de ces délégations conformément à ses politiques et procédures. | |
| Évaluation des mesures de protection | Évaluation visant à déterminer si une chaîne demandée doit être assortie de mesures de protection spécifiques relatives à la protection du consommateur, aux chaînes sensibles et aux marchés règlementés. Voir la Section 7.8.2 Engagements en faveur de la protection de l’intérêt public. | |
| PIC à des fins de protection | Les PIC à des fins de protection ont été élaborés et mis en œuvre conformément à l’avis consensuel du GAC, énoncé dans le communiqué de Beijing de la réunion ICANN46, et à la résolution adoptée subséquemment par le Conseil d’administration de l’ICANN lors de la série 2012 du programme des nouveaux gTLD. L’ICANN classe les gTLD nécessitant des PIC à des fins de protection (voir la Section 7.8.2.2 PIC à des fins de protection applicables par catégorie de chaîne) en quatre groupes de risque, à savoir : Secteurs hautement réglementés/conditions d’admission libre : chaînes qui, tout en inspirant la confiance des consommateurs, présentent des risques élevés ; Secteurs hautement règlementés/conditions d’admission restrictives : chaînes liées à des secteurs d’activité qui requièrent une licence ou une accréditation ; Risque de cyberintimidation ou de harcèlement : chaînes pouvant faciliter le harcèlement ; Fonctions intrinsèquement gouvernementales : chaînes associées à des domaines gouvernementaux. | |
| Script | Ensemble de lettres et autres signes écrits utilisés pour représenter des informations textuelles dans un ou plusieurs systèmes d’écriture. Par exemple, le russe utilise un sous-ensemble du script cyrillique ; l’ukrainien en utilise un sous-ensemble différent. Le système d’écriture japonais utilise plusieurs scripts. | |
| Évaluation de la notification des singuliers/pluriels | L’ICANN examinera les documents soumis au titre du processus de notification des singuliers/pluriels afin de déterminer si certaines chaînes correspondent aux formes singulière et plurielle d’un même mot dans une même langue. Se reporter à la Notifications relatives aux formes singulier/pluriel. | |
| Chaîne | La chaîne de caractères composant un gTLD faisant l’objet d’une candidature ou ses variantes de chaîne. | |
| Objection relative à des chaînes prêtant à confusion | Objection déposée au motif que la chaîne faisant l’objet d’une candidature à un gTLD présente une similitude pouvant prêter à confusion avec un TLD existant ou avec une chaîne faisant l’objet d’une autre candidature à un gTLD, déposée dans le cadre de la même série de candidatures. Se reporter à la Section 4.5.1.1 Motif d’objection : chaînes prêtant à confusion. | |
| Conflit de chaînes | Situation où plusieurs candidats sont qualifiés pour le même gTLD ou pour des gTLD dont la similarité peut prêter à confusion pour les utilisateurs au cas où plus d’une chaîne serait déléguée dans la zone racine. Reportez-vous à la Section 5.2 Conflits de chaînes et procédures de résolution. | |
| Évaluation de chaînes | L’évaluation de chaînes (voir la Section 1.2.4 Évaluation de chaîne) porte exclusivement sur les chaînes faisant l’objet de la candidature et leurs variantes allouables. Elle se compose de cinq volets, examinés simultanément : l’évaluation de la similarité des chaînes (voir la Section 7.10 Évaluation de la similarité de chaînes) ; l’évaluation initiale de la collision de noms (voir la Section 7.7.2 Évaluation initiale de la collision de noms) ; l’évaluation des engagements en faveur de la protection de l’intérêt public (voir la Section 7.8.2 Engagements en faveur de la protection de l’intérêt public) ; l’identification de noms géographiques (voir la Section 7.5 Noms géographiques) et l’évaluation des notifications relatives aux formes singulier/pluriel (voir la Section 4.4 Notifications relatives aux formes singulier/pluriel). | |
| Évaluation de la similarité de chaînes | L’évaluation de la similarité de chaînes (voir la Section 7.10 Évaluation de la similarité de chaînes) consiste à comparer des candidatures à un gTLD entre elles, ainsi qu’avec des TLD existants, avec des gTLD et des ccTLD dont la procédure de candidature est toujours en cours, avec des noms bloqués (voir la Section 7.2 Aperçu des noms bloqués et réservés) et avec toute chaîne ASCII à deux caractères (c’est-à-dire un ccTLD potentiel). | |
| Procédures pour des séries ultérieures | SubPro | Toute introduction de nouveaux gTLD après la série de 2012. Terme lié au processus d’élaboration de politiques sur les procédures pour des séries ultérieures de nouveaux gTLD et au rapport final16 correspondant, qui présente l’ensemble des recommandations pour la série 2026 du programme des nouveaux gTLD. |
| Délégation temporaire | Les chaînes (ainsi que leurs variantes) qui ne sont pas jugées à haut risque lors de l’évaluation initiale (voir la Section 7.7.2 Évaluation initiale des collisions de noms) sont placées en file d’attente pour une délégation temporaire (voir la Section 7.7.3 Délégation temporaire et évaluation finale). La délégation temporaire commence dès la clôture de l’évaluation initiale, même si d’autres évaluations relevant de l’évaluation de la chaîne sont encore en cours. L’ordre de priorité pour la délégation temporaire est déterminé par le numéro de priorité attribué à la candidature. | |
| Système de gestion des candidatures aux TLD | TAMS | Système sécurisé permettant aux candidats de soumettre les informations requises pour déposer une demande à une ou plusieurs composantes du programme des nouveaux gTLD, qu’il s’agisse du programme de soutien aux candidats, de la préévaluation des fournisseurs de services de registre, ou de la candidature à un gTLD. |
| Domaine de premier niveau | TLD | Les domaines de premier niveau (« TLD ») sont les noms situés en haut de la hiérarchie de nommage du DNS. Dans un nom de domaine, ils représentent la suite de lettres qui se trouve juste après le dernier point, comme « NET » dans « www.exemple.net ». L’administrateur d’un TLD contrôle les noms de second niveau qui sont reconnus dans ce TLD. Les administrateurs du domaine racine ou de la zone racine contrôlent les TLD qui sont reconnus par le DNS. |
| Centre d’échange d’information sur les marques | TMCH | Mécanisme conçu pour la protection des droits des titulaires de marques. Le Centre d’échange d’information sur les marques vérifie et enregistre des informations relatives aux droits de marques dans le monde entier. Les données vérifiées sont ensuite utilisées au cours du processus d’enregistrement d’un nom domaine, en particulier lors du lancement de nouveaux gTLD. |
| Base de données des marques | TMDB | Composante du Centre d’échange d’information sur les marques, la base de données des marques fournit aux opérateurs de registre et aux bureaux d’enregistrement une interface leur permettant de satisfaire aux exigences de certains mécanismes de protection des droits. |
| Politique uniforme de règlement de litiges relatifs aux noms de domaine | UDRP | Politique régissant le règlement des litiges découlant de l’enregistrement abusif de noms de domaine (par exemple, pour le cybersquattage) ; elle prévoit à cette fin des procédures administratives accélérées que le titulaire d’une marque peut engager en déposant une plainte auprès d’un fournisseur de services de règlement de litiges approuvé. |
| Système uniforme de suspension rapide | URS | Procédure administrative accélérée que les titulaires de droits peuvent engager pour certains types de litiges relatifs aux noms de domaine. La procédure URS est un outil qui apporte une réponse rapide à des cas spécifiques d’atteinte aux marques. |
| Langues officielles des Nations Unies | Langues UN6 | Les six langues utilisées aux Nations Unies : anglais, arabe, chinois, espagnol, français et russe. |
| Évaluation des variantes de chaînes | Le candidat qui sollicite une ou plusieurs variantes allouables d’une chaîne principale faisant l’objet d’une candidature, ou d’un gTLD existant, doit justifier la nécessité de chacune d’elles. Cette justification est évaluée (voir la Section 7.6 Évaluation des variantes de chaînes) par un panel sur la base des critères applicables spécifiés dans la recommandation de politique issue de l’étape 1 de l’EPDP sur les IDN. Les variantes ayant réussi l’évaluation sont intégrées à la spécification 14 du contrat de registre de base. Voir l’Annexe 4 Contrat de registre de base. | |
| Variante de chaîne | Chaîne considérée « identique » à une autre chaîne par la communauté de script concernée, et de ce fait générée en tant que variante de la chaîne principale, conformément à un ensemble spécifique de règles de génération d’étiquettes (LGR). Pour le premier niveau, la variante d’une chaîne est définie au moyen des règles de génération d’étiquettes pour la zone racine (RZ-LGR). | |
| Ensemble de variantes de chaîne | Désigne l’ensemble constitué de la chaîne principale, de ses variantes allouables et de ses variantes bloquées. Pour un gTLD existant, la chaîne principale correspond au gTLD par rapport auquel l’ensemble de variantes sera calculé et soumis. Pour le premier niveau, les ensembles de variantes de chaîne sont créés en appliquant les règles de génération d’étiquettes pour la zone racine (RZ-LGR) à la chaîne primaire. | |
Similarité visuelle -ou- Visuellement similaire à |
Il y a similarité visuelle lorsque deux ou plusieurs chaînes se ressemblent visuellement au point de prêter à confusion et de créer un risque de méprise pour l’utilisateur si leur coexistence était autorisée. Reportez-vous à la Section 5.2 Conflits de chaînes et procédures de résolution. | |
| Groupe de travail | WG | Groupe provisoire formé par une organisation de soutien ou un comité consultatif afin de résoudre un problème spécifique ou de mener une tâche précise. |
| Fichier de zone | Fichier sur un serveur de noms faisant autorité qui définit le contenu d’une zone dans le système de noms de domaine. Les enregistrements de ressources (RR) dans un fichier de zone identifient les adresses IP des hôtes (par exemple, des serveurs Web, des serveurs de messagerie) et les serveurs de noms dans la zone du serveur de noms. Un fichier de zone peut également contenir d’autres types de RR (tels que ceux contenant les signatures numériques) tel que cela est déterminé par le propriétaire de zone. Les RR dans un fichier de zone permettent à un serveur de noms faisant autorité de répondre définitivement aux requêtes DNS sur le contenu d’une zone. |
Se reporter aux statuts constitutifs de l’ICANN : https://www.icann.org/en/governance/bylaws.↩︎
Se reporter au Rapport final SubPro : https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎
Voir le Rapport final de la révision de la concurrence, de la confiance et du choix du consommateur : https://www.icann.org/en/system/files/files/cct-rt-final-08sep18-en.pdf.↩︎
Voir l’Annexe A des statuts constitutifs de l’ICANN : http://www.icann.org/en/general/bylaws.htm#AnnexA.↩︎
Voir le site Web des parties contractantes : http://www.icann.org/en/general/consensus-policies.htm.↩︎
Voir la base de données de la zone racine : http://iana.org/domains/root/db/.↩︎
Voir la liste de la base de données de la zone racine : https://www.iana.org/domains/root/db.↩︎
Voir le Rapport final du processus d’élaboration de politiques consacré aux procédures pour des séries ultérieures de nouveaux gTLD : https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-20jan21-en.pdf.↩︎
Voir la page Web de la GNSO : https://gnso.icann.org/en.↩︎
Voir la liste du patrimoine mondial de l’UNESCO : https://whc.unesco.org/en/list/&order=region.↩︎
Voir la section régions géographiques de la norme M49 : https://unstats.un.org/unsd/methodology/m49/.↩︎
En savoir plus sur le Conseil d’administration : https://www.icann.org/en/board/about.↩︎
Voir le site Web de l’organisation ICANN : https://www.icann.org/.↩︎
Voir la liste des bureaux d’enregistrement accrédités : https://www.icann.org/en/accredited-registrars.↩︎
Voir la Révision de la mise en œuvre du programme du 29 janvier 2016 : https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf.↩︎
Voir le Rapport final du processus d’élaboration de politiques consacré aux procédures pour des séries ultérieures de nouveaux gTLD : https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎