Résumé

  • Les restrictions de couverture de RFC 8008 se cumulent pour réduire l’ensemble des sources admissibles. Une liste juxtaposant IPv4 et IPv6 peut ainsi ne correspondre à aucun client.
  • RFC 9388 introduit une union explicite, sans convertir toutes les restrictions environnantes en alternatives. Une capacité doit rester attachée à la zone dans laquelle elle est disponible.
  • Ni une carte de couverture, ni une annonce authentifiée, ni un conseil de capacité ne garantit à lui seul la bonne exécution d’une demande. La gouvernance consiste à rendre ces limites lisibles sans centraliser chaque décision.

Le territoire dessiné par un « et »

Une équipe élargit son annonce de couverture. Elle disposait d’un objet décrivant un préfixe IPv4 ; elle ajoute un objet pour un préfixe IPv6. Le geste paraît aller dans le sens attendu : permettre aux partenaires d’orienter des demandes issues des deux familles d’adresses vers le réseau aval. Sur une carte commerciale, deux ensembles remplaceraient un seul.

La difficulté est que le message n’emploie pas nécessairement le « ou » que son auteur avait en tête. Dans l’annexe B de RFC 8008, les différentes restrictions de couverture resserrent cumulativement la liste des candidats. L’adresse source utilisée pour la décision doit respecter chacune d’elles.

Une adresse ne peut pas être à la fois une adresse IPv4 appartenant au premier préfixe et une adresse IPv6 appartenant au second. Le résultat est un ensemble vide. La figure 2 de RFC 9388 présente précisément cet exemple. Il ne s’agit pas d’un incident de production imputé à un opérateur.

Il ne s’agit pas davantage d’une objection au double protocole. Un terminal peut utiliser les deux familles. La contrainte porte sur l’adresse source examinée pour une décision donnée, et non sur toutes les possibilités du terminal pendant toute sa vie.

Le nombre de préfixes annoncés augmente donc alors que le nombre de sources admissibles devient nul. Aucun inventaire des mots-clés « IPv4 » et « IPv6 » ne suffit à découvrir le problème. Ce qui manque au raisonnement intuitif est la relation entre les objets : leurs conditions sont-elles conjointes, ou représentent-elles des alternatives ?

Cette relation est déjà une décision de gouvernance. Elle détermine les demandes pour lesquelles un partenaire accepte d’être considéré. Un système qui remplace silencieusement la conjonction par une union ne se contente pas d’améliorer la présentation : il modifie la portée de l’annonce reçue.

Un candidat n’est pas un service accompli

CDNI permet à des réseaux de distribution de contenu de coopérer, notamment pour étendre leur portée. Le problème initial et les cas d’usage décrivent cette coopération. Ils ne supposent pas que tous les participants possèdent les mêmes ressources ou proposent une prestation interchangeable en tout lieu.

Le cadre CDNI distingue plusieurs interfaces. La publicité des capacités aide à choisir un réseau aval ; la redirection organise une autre étape ; les métadonnées portent les conditions associées au contenu. Le contrôle et les journaux ont également leurs fonctions. L’existence d’une annonce ne démontre pas qu’une demande ultérieure a été exécutée.

RFC 8008 privilégie le modèle des capacités assorties de restrictions de couverture. La capacité n’est pas une case globale attachée au nom d’un opérateur. Le réseau peut prendre en charge HTTPS dans une partie de sa zone et ne pas le prendre en charge ailleurs, par exemple pendant une maintenance ou parce que les ressources qui desservent cette autre partie diffèrent.

La formule « le partenaire prend en charge HTTPS et couvre ces zones » peut être vraie dans un sens agrégé tout en étant impropre à une demande concrète. Elle ne dit pas que HTTPS est disponible pour la source située dans la zone choisie. L’agrégation a perdu le lien qui permettait de rapprocher le besoin et la prestation.

Le raisonnement devient plus fragile encore lorsqu’il faut plusieurs fonctions. Acquérir le contenu depuis un réseau amont ou une origine n’est pas le même rôle que le livrer au demandeur. Une annonce de protocole d’acquisition ne vaut pas annonce du protocole de livraison.

Lorsque l’arrangement choisi exige plusieurs capacités, chacune doit être établie dans la portée pertinente. Réunir les zones où ces capacités existent séparément ne crée pas un endroit où elles sont toutes utilisables ensemble. Cela ne commande pas un questionnaire universel pour chaque contenu : les besoins restent propres au service. Cela interdit seulement de transformer des vérités disjointes en une compatibilité commune non démontrée.

L’union a sa place, pas tous les pouvoirs

La fiche actuelle de RFC 8008 indique que RFC 9388 le met à jour. Le modèle de 2016 ne doit donc pas être présenté comme une liste définitivement close de possibilités.

Publié en juillet 2023, RFC 9388 fournit le type footprintunion. Celui-ci regroupe plusieurs objets de couverture pour exprimer des alternatives. En plaçant les objets IPv4 et IPv6 à l’intérieur de cette union, on peut représenter les deux populations que la juxtaposition précédente excluait.

Le changement reste explicite. Il ne réécrit pas toutes les listes de couverture pour leur donner automatiquement un sens extensif. Une restriction conservée à l’extérieur de l’union continue de s’appliquer. Le document montre ainsi un ASN combiné à une union de zones géographiques : la branche géographique retenue doit encore respecter la condition extérieure.

C’est une limite importante du mot « simplification ». Une union d’unions peut être ramenée à une union simple sans changer les alternatives. RFC 9388 interdit d’ailleurs qu’une footprintunion contienne une autre footprintunion. En revanche, supprimer une restriction qui encadre l’union change l’ensemble des clients concernés.

Une représentation plus courte est utile si elle conserve le sens. Elle ne l’est plus si elle efface ce que le réseau aval avait exclu. La comparaison pertinente n’est pas le nombre de lignes avant et après transformation, mais le résultat obtenu pour une même adresse source.

Deux erreurs opposées naissent de la même lecture superficielle. On peut rétrécir involontairement la zone jusqu’au vide en cumulant des conditions incompatibles. On peut aussi l’élargir abusivement en prenant chacune des conditions pour une voie alternative. Une carte plaisante ne départage pas ces erreurs ; la structure logique le fait.

La couverture n’est pas l’emplacement des machines

Dans le langage courant, couvrir une zone signifie souvent y avoir une présence. Pour CDNI, la description porte sur les sources dont le réseau est disposé à servir les demandes, pas uniquement sur les lieux où se trouvent ses serveurs.

Un réseau construit par un fournisseur d’accès peut disposer de ressources proches de ses abonnés. Ces ressources peuvent être joignables depuis d’autres réseaux sans que leur propriétaire souhaite accepter toutes les demandes externes. La joignabilité publique ne suffit pas à établir la volonté commerciale et opérationnelle de livrer.

Les descripteurs eux-mêmes ont des limites. Une liste d’ASN nécessite une interprétation des plages d’adresses associées. RFC 8008 ne fournit pas une méthode universelle faisant autorité pour cette association. Il ne définit pas non plus une méthode unique par laquelle tous les réseaux amont attribueraient un pays à une source.

RFC 9388 ajoute subdivisioncode, fondé sur ISO 3166-2, pour exprimer une zone géographique plus fine. La précision du vocabulaire n’est pas une preuve de précision de la mesure. Nommer une subdivision ne garantit pas que la demande a été correctement située, ni que toutes les étapes de traitement ou toutes les copies de contenu y résident.

Le registre des paramètres CDNI stabilise les identifiants et les définitions des types. Il ne certifie pas l’appartenance de chaque demande à une zone. Cette appréciation dépend encore des éléments et conventions utilisés par les participants.

Une annonce peut donc être parfaitement lisible tout en reposant sur une attribution incertaine de la source. La bonne discipline est de reconnaître cette séparation. La couleur d’une carte ne transforme pas une inférence locale en vérité commune.

Ce qu’un réseau aval tient d’un autre

La couverture d’un partenaire peut inclure les services d’un réseau situé plus loin dans une chaîne de délégation. Une capacité disponible pour le premier partenaire n’a pas nécessairement son origine dans les seules ressources de ce partenaire.

L’exemple de l’annexe A de RFC 8008 pose justement la question d’une capacité de livraison fournie par un réseau aval transitif dans une partie d’une zone. Si cette contribution disparaît, le réseau amont doit pouvoir comprendre ce qui change pour son choix du partenaire de premier niveau.

La perte peut rester limitée : une capacité, dans une sous-zone, dépendait de la contribution devenue indisponible. Elle ne signifie pas forcément que le partenaire entier ne peut plus servir personne. Mais conserver une annonce globale inchangée peut rendre certains choix incompatibles avec la nouvelle situation.

C’est un argument en faveur de déclarations ciblées plutôt que d’un inventaire total de la topologie. RFC 8008 souligne que des descriptions fondées sur les ressources peuvent exposer l’organisation interne d’un réseau ; elles ne sont pas rendues universellement obligatoires.

L’amont a surtout besoin de savoir quelle prestation demeure proposée pour quelles sources. Une information circonscrite peut préserver les décisions relatives aux zones et fonctions non touchées. La limitation de la déclaration n’est pas un défaut lorsque c’est précisément la limitation du changement réel.

La difficulté politique vient du nom unique sur la carte. Le nom du partenaire reste, alors qu’une capacité locale dont dépendait la décision n’existe plus. Sans la portée propre à cette capacité, l’agrégat paraît conserver une promesse qu’il ne permet déjà plus de vérifier.

Les conditions du contenu ne disparaissent pas dans l’annonce

Une demande peut correspondre à la couverture annoncée et concerner un contenu que le réseau aval ne doit pas servir. RFC 8006 distingue le traitement des métadonnées de l’exécution des règles qu’elles portent.

Une métadonnée obligatoire à faire respecter ne devient pas facultative parce que l’annonce FCI paraissait favorable. Si sa fonction n’est pas comprise ou ne peut pas être exécutée, le contenu correspondant ne doit pas être servi. La connaissance préalable des capacités ne dispense pas le réseau aval d’évaluer les métadonnées associées à la demande.

Il peut également être possible de transmettre certaines métadonnées sans pouvoir servir soi-même le contenu, lorsque leurs règles de redistribution le permettent. Transiter correctement et exécuter localement sont deux pouvoirs distincts. Une capacité à passer l’information ne prouve pas la capacité à respecter la condition au point de livraison.

RFC 8008 autorise, dans le cadre de la gestion définie par un protocole concret, l’ignorance de types optionnels non reconnus. L’extensibilité doit être négociée et les cas non pris en charge doivent avoir un traitement. Cette tolérance ne constitue pas une preuve qu’une exigence inconnue du service est satisfaite.

Le document d’exigences CDNI éclaire les objectifs des interfaces, sans les fusionner en une garantie générale de bon fonctionnement. Il faut conserver à la fois les conditions de candidature et les obligations propres au contenu. Un choix d’orientation favorable ne règle pas toute la décision de livraison.

La capacité chiffrée ne réserve pas une place

Le paysage actuel ne se limite pas aux cinq types de capacité initialement définis par RFC 8008. Le registre comprend notamment FCI.Telemetry et FCI.CapacityLimits, introduits par RFC 9808 en juillet 2025. Dire que FCI ne peut jamais transmettre d’information de charge serait désormais faux.

L’extension fournit des informations d’utilisation et des limites destinées à éclairer la délégation. Elle précise qu’il s’agit de conseils, et non d’une garantie, d’un engagement ou d’une réservation de capacité. La limite garde la portée de l’annonce qui la contient.

Toutes les limites applicables doivent être prises en compte conjointement, plutôt que de ne choisir que celle qui paraît la plus spécifique. Ce principe n’efface pas les contraintes de couverture : une marge apparente ne rend pas admissible une source exclue et ne fournit pas une capacité de sécurité absente.

Il faut aussi comparer la limite et l’utilisation qui lui correspond. Une mesure provenant d’une autre source, portant sur une autre zone ou agrégeant une autre période peut ne pas répondre à la question posée. Le retard de la télémétrie affecte l’interprétation d’un ajustement, sans transformer une observation en place réservée.

Ce n’est pas un retour à un centre qui autoriserait chaque demande. C’est une information supplémentaire pour la décision locale de l’amont. L’aval décrit ses limites ; l’amont choisit la délégation ; le résultat futur reste autre chose que le conseil disponible au moment du choix.

Une zone nommée a besoin de son contexte

RFC 9241, dont la fiche RFC Editor permet de retrouver le statut, spécifie le transport des annonces CDNI au moyen d’ALTO. Le protocole rend les annonces récupérables dans un cadre concret ; il ne remplace pas les significations définies par RFC 8008.

Un objet peut se référer à un PID ALTO dont le sens dépend d’une carte réseau. Le cadre du protocole ALTO associe ces informations à des ressources et versions. L’annonce indique la ressource dont elle dépend et le repère de version correspondant.

Un identifiant stable ne signifie donc pas que l’ensemble d’adresses associé n’a jamais changé. Rapprocher une annonce d’une carte d’une autre version peut déplacer silencieusement les sources auxquelles on applique la capacité. La cohérence recherchée concerne le sens de la référence ; elle n’exige pas une horloge mondiale synchronisée entre tous les réseaux.

Un autre contraste mérite attention. Dans RFC 9241, une liste vide de capacités annoncées signifie l’absence de capacités obligatoires à implémenter pour toute zone. Mais une liste de couverture absente, nulle ou vide à l’intérieur d’un objet de capacité signifie une couverture globale pour les capacités de cet objet. Le même adjectif « vide » ne produit pas le même effet à ces deux niveaux.

Les annonces filtrées conservent le repère de version de l’annonce complète dont elles proviennent. Le filtrage facilite une consultation ciblée ; il ne donne pas automatiquement des conclusions sur toutes les zones qui n’ont pas été demandées.

Les cartes de propriétés d’entités ALTO définissent l’héritage en fonction des domaines. Le domaine des subdivisions géographiques introduit par RFC 9388 ne possède ni hiérarchie ni héritage de propriétés. Il serait erroné de lui importer les règles des préfixes d’adresses.

Les mises à jour incrémentales ALTO permettent de communiquer des changements plus efficacement. Elles aident à suivre une déclaration, sans réparer une interprétation logique incorrecte. Recevoir plus vite une carte ne change pas le « et » en « ou ».

Une langue commune, des décisions distinctes

RFC 8008 impose l’intégrité et l’authentification aux protocoles qui transportent ces annonces. Une fausse annonce supprimant toute couverture pourrait empêcher la délégation. Vérifier l’origine du message est indispensable ; cela ne garantit pas l’exactitude de la zone, la qualité du service ou la disponibilité d’une capacité réservée.

Les accords commerciaux, l’expérience et des vérifications ultérieures restent pertinents. Le vocabulaire commun permet de comprendre la déclaration, sans prétendre remplacer tous les éléments qui déterminent si elle mérite confiance.

L’argument de Lu Heng sur la spécification initiale minimale éclaire cette architecture. Il faut assez de sens partagé pour établir l’arrangement initial. Les décisions futures demeurent locales ; les extensions peuvent être adoptées volontairement lorsque les participants les comprennent et disposent d’un usage réel.

Cette liberté ne permet pas de retirer une obligation déjà acceptée à l’insu du partenaire qui s’y fie. Adopter une union ouvre des alternatives précisées, sans abolir les contraintes qui les entourent. Refuser une extension que l’on ne sait pas interpréter est différent de la considérer silencieusement comme satisfaite.

The Policy Mirror invite à regarder la surface où une règle devient une décision pratique. Ici, cette surface est la lecture de l’annonce : portée, combinaison des conditions et sens des références. Un affichage peut en dire moins que le message tout en donnant l’impression de le résumer complètement.

La carte CDNI n’a pas besoin d’être immense pour être utile. Elle a besoin de conserver les limites de la prestation proposée. Une union explicite peut réellement élargir le choix. Un agrégat qui efface les conditions ne fait qu’élargir l’apparence de la promesse.