Domaine principal
Gouvernance de l’Internet et routage
Au sein de la facette Domaine principal, l'analyse Gouvernance de l’Internet et routage regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.

ICANN
ICANN : de la coordination des identifiants à l’exécution contractuelle
L’autorité d’ICANN ne vient pas d’un pouvoir public général. Elle se construit par couches: objet social et statuts, règles élaborées par une communauté multipartite, contrats conclus avec les registres et bureaux d’enregistrement, puis opérations techniques qui maintiennent les…

IETF
IETF-W3C : deux systèmes d’autorité sous une même étiquette
L’étiquette IETF-W3C suggère parfois une institution unique. Les textes de référence décrivent pourtant deux systèmes de contrôle distincts: le processus de normalisation de l’IETF, ses organes et ses voies d’appel d’une part; le processus technique, les accords d’adhésion et les…

ICANN
Les recours d’ICANN ne sont pas interchangeables : qui peut contester quoi ?
Chez ICANN, une objection ne devient pas automatiquement un recours. Elle doit entrer dans un instrument précis, franchir ses conditions d’accès et atteindre l’organe auquel les statuts confient la décision. Cette architecture distingue le pouvoir de la communauté de rejeter…

Récits
DATAMATIX et AS210973 : ce que les registres et le routage peuvent réellement prouver
Une enquête sur la différence entre une inscription publique, une déclaration de politique de routage, une observation BGP et une continuité opérationnelle démontrée.

ICANN
La 5e variante attribuable déclenche de nouveaux frais d’évaluation
Pour un nouveau demandeur, les quatre premières chaînes de variantes peuvent être incluses; chaque variante attribuable supplémentaire au-delà de la quatrième entraîne des frais complets d’évaluation de 227 000 USD.

ICANN
Une candidature gTLD déposée garde un délai de paiement de sept jours
Un dépôt gTLD dans les délais ne suffit pas: l’ICANN doit recevoir les frais d’évaluation pendant la fenêtre de paiement distincte.

ICANN
Le contrôle administratif est un filtre de dépôt, pas une décision au fond
Le contrôle administratif de l’ICANN vérifie le dépôt et prépare les ensembles de chaînes identiques sans constituer une décision au fond.

ICANN
Une évaluation RSP peut couvrir plusieurs gTLD — seulement pour les services qualifiés
Une évaluation peut être réutilisée pour plusieurs gTLD, mais la qualification ICANN reste liée à des services précis.

ICANN
La couverture RSP est une carte de fonctions, pas un nombre de prestataires
Un candidat peut nommer plusieurs prestataires de services de registre tout en laissant une fonction critique sans couverture. Le cadre ICANN du cycle 2026 distingue les rôles Main, DNS, DNSSEC et Proxy facultatif, avec des fonctions et des limites de nombre propres à chacun.

ICANN
Nommer un RSP ne vaut pas confirmation lors de la contractualisation
Un candidat peut désigner un prestataire de services de registre dans son dossier, tandis que l’ICANN lui demande séparément une confirmation lors de la contractualisation. Le choix du candidat, la demande de l’ICANN et toute réponse effective du RSP constituent des preuves…

ICANN
Le choix des RSP peut attendre l’évaluation, pas indéfiniment
Les règles ICANN 2026 permettent de déposer une candidature sans nommer les prestataires de services de registre, mais exigent la couverture des fonctions critiques minimales au stade de l’évaluation.

ICANN
Les ensembles de variantes entrent ensemble en concurrence
Les règles ICANN 2026 traitent la chaîne principale et ses variantes attribuables demandées comme une seule unité de concurrence lorsque plusieurs candidats visent le même ensemble de variantes.

ICANN
Les demandes de variantes de gTLD existants sont prioritaires, sans être approuvées
ICANN accorde une place plus précoce dans l’ordre de traitement à une catégorie de demandes: les variantes attribuables de gTLD existants issus du cycle 2012. Cette priorité modifie l’ordre, pas l’issue de fond.

ICANN
Les variantes d’un gTLD existant placent le registre sous un seul contrat 2026
Un opérateur qui demande des variantes attribuables d’un gTLD existant n’ajoute pas des libellés isolés à un contrat inchangé. Les règles ICANN 2026 imposent le passage au nouveau contrat de registre de base et réunissent le gTLD existant et ses variantes dans un seul contrat.

ICANN
Seul l’opérateur du gTLD existant peut demander ses variantes IDN
Pour le cycle ICANN 2026, le demandeur de variantes IDN d’un gTLD existant doit être la même personne morale que l’opérateur de registre de ce gTLD.

ICANN
Les variantes IDN doivent partager le prestataire de registre du gTLD principal
Pour le cycle ICANN 2026, un gTLD IDN principal et ses variantes doivent utiliser le même prestataire de services de registre back-end pendant leur délégation.

ICANN
Le retrait d’une demande IDN principale retire aussi ses variantes
Pour le cycle ICANN 2026, le retrait d’une demande visant un IDN principal entraîne aussi le retrait de toutes les chaînes variantes demandées avec lui.

ICANN
Une demande de variante IDN ne peut pas précéder sa chaîne principale
Pour le cycle ICANN 2026, une demande portant sur une variante IDN allouable ne peut pas être déposée avant celle du gTLD IDN principal auquel elle se rattache.

ICANN
Pour un IDN principal proposé, le choix peut changer les variantes allouables
Lorsque le principal proposé n’est pas un gTLD existant, le nombre total de chaînes de l’ensemble de variantes RZ-LGR reste inchangé, mais les sous-ensembles de variantes allouables et bloquées peuvent changer avec ce choix.

ICANN
ICANN autorise le retrait de variantes IDN après le dépôt, mais pas leur ajout
Pour le cycle 2026, le dépôt fixe l’ensemble initial formé par l’IDN principal et ses variantes demandées: il peut ensuite être réduit par retrait, mais pas élargi.
