Résumé

  • Diffusé le 17 août, le projet précise et remplace les passages pertinents de la contribution SG2-C-0196 : le RIPE NCC soutient la poursuite d’ENUM public sous e164.arpa et ne demande plus à l’UIT-T de trancher seul son avenir technique.
  • Sur 46 délégations examinées, 23 ne présentaient pas de problème DNS au niveau supérieur, 17 semblaient hors service et six avaient des défauts partiels. Les 23 cas problématiques sont maintenant qualifiés de travail de maintenance et d’exactitude des données.
  • Le texte demande au Groupe d’études 2 de confirmer en septembre les procédures révisées pour les délégations non opérationnelles ou temporaires expirées. Il reste soumis aux commentaires jusqu’au 25 août et ne constitue encore ni décision ni suppression.

Une même mesure ne peut pas répondre à deux décisions

ENUM public relie deux systèmes qui n’ont pas le même administrateur. L’UIT présente ENUM comme une méthode d’inscription des indicatifs E.164 dans le DNS. La norme RFC 6116 décrit la transformation d’un numéro de téléphone en nom DNS et la recherche d’identifiants de communication.

Le domaine e164.arpa appartient à l’infrastructure arpa, sous la responsabilité architecturale de l’IAB. Le RIPE NCC en assure l’exploitation déléguée. L’UIT-T coordonne la partie liée au plan de numérotation E.164, tandis que les autorités nationales et les opérateurs désignés maintiennent les délégations. Le RFC 3245 documente cet agencement coopératif.

La contribution de février SG2-C-0196 était partie d’une question plus étroite : faut-il offrir les objets ENUM par RDAP ? Elle avait cependant étendu l’interrogation au statut futur d’ENUM et de e164.arpa. Après les échanges avec l’IAB, les opérateurs de délégation et la communauté RIPE, le nouveau projet reconnaît que cette extension décrivait mal la répartition des responsabilités.

La rectification n’est pas ambiguë. Le RIPE NCC soutient la continuité d’ENUM public et n’en propose pas la fermeture. Les passages pertinents du texte de février sont remplacés. Le Groupe d’études 2 n’est plus invité à déterminer à lui seul l’avenir technique ou architectural du système ; il est invité à rendre utilisable la procédure concernant chaque délégation défaillante.

La moitié d’un inventaire est un problème, pas un plébiscite

Le contrôle de 46 délégations a produit une symétrie saisissante. Vingt-trois répondaient sans problème DNS détecté au niveau supérieur. Dix-sept paraissaient inopérantes. Six présentaient une anomalie partielle. Au total, 23 dossiers méritaient donc une investigation.

Ce résultat ne doit pas être minimisé. Un registre qui conserve des délégations abandonnées ou mal configurées cesse de décrire fidèlement ce qui fonctionne. Mais le test ne dit pas tout ce qu’il faudrait savoir pour décider. Il ne distingue pas nécessairement un abandon durable d’une migration, d’une panne passagère, d’une erreur de serveur faisant autorité ou d’un projet de remise en service. Il ne mesure ni les utilisateurs, ni les usages nationaux, ni le coût de rupture.

Le projet d’août pose la bonne limite probatoire : l’inventaire révèle un problème de maintenance du registre et d’exactitude des données, sans suffire à conclure sur l’ensemble d’ENUM. Chaque cas peut recevoir une cause, un interlocuteur et une action. Les délégations en état ne sont plus utilisées comme accessoires d’une question de fermeture générale.

Le changement de doctrine tient dans l’unité de traitement. Un constat sur 23 délégations appelle 23 dossiers étayés, pas une seule décision sur le destin du domaine.

La réunion de septembre doit activer une méthode

Le compte rendu de la réunion de février du SG2 indique que les procédures provisoires révisées, contenues dans TD423 Rev.1/PLEN, ont été approuvées pour entrer en vigueur lors de la réunion suivante, du 9 au 18 septembre, sous réserve des conclusions tirées de la consultation lancée par circulaire.

La circulaire TSB 123 sollicitait l’avis des États membres sur la fermeture possible des délégations d’indicatifs E.164 sous e164.arpa. La liaison adressée à l’IAB fixait le 15 août comme échéance. Le projet du RIPE NCC propose d’utiliser ces réponses pour comprendre l’intention et l’état de chaque délégation nationale, non pour additionner des votes et produire une conclusion technique globale.

La demande à SG2 devient donc vérifiable. Confirmer, d’une part, que TD423 Rev.1/PLEN entre en vigueur et constitue le mécanisme applicable aux délégations non opérationnelles ou temporaires expirées. Maintenir, d’autre part, la coordination avec l’IAB, le RIPE NCC, les processus pertinents de l’IETF et les parties concernées pour toute question plus large.

Une fois la procédure active, le RIPE NCC prévoit de refaire l’évaluation technique, de contacter les opérateurs lorsque cela est possible et de transmettre au Bureau de normalisation des cas suffisamment étayés. Cet ordre protège contre l’automatisme : une mesure ancienne n’est pas transformée directement en instruction de retrait.

La réponse de l’IAB a remis les rôles dans le bon ordre

La liaison envoyée par l’IAB en juin reconnaît que les États peuvent apporter des informations opérationnelles utiles. Elle refuse cependant qu’une telle consultation décide, à elle seule, du sort de e164.arpa ou du statut d’ENUM. Le classement éventuel du RFC 6116 comme historique relève du processus ouvert de l’IETF ; la fin du domaine exigerait une coordination entre les organismes techniques et opérationnels concernés.

Cette distinction décrit aussi qui peut prouver quoi. Une autorité nationale connaît l’intention attachée à son indicatif. Un opérateur sait s’il peut réparer ses serveurs. Le RIPE NCC peut observer le DNS, maintenir la zone et établir une chronologie. Le SG2 et le TSB disposent du canal de coordination E.164. L’IETF dispose du processus de normalisation. Le dossier devient solide quand ces preuves s’emboîtent, pas lorsqu’une institution emprunte la compétence d’une autre.

Le nouveau texte du RIPE NCC adopte enfin cette géométrie. Il ne renonce pas à l’entretien de la zone. Il renonce à faire porter à cet entretien la décision sur l’existence du système.

Une présentation indépendante du RIPE NCC cite la coordination ENUM parmi ses services. Le Policy Mirror de Lu Heng fournit le critère de retenue : la légitimité d’un registre vient de la précision d’une fonction circonscrite, non de la conversion d’une observation de maintenance en pouvoir sur tout l’écosystème.

RDAP retrouve sa juste dimension

Le projet précise aussi que l’ajout d’un accès RDAP aux objets ENUM est distinct de la continuité d’ENUM public. L’absence d’une interface moderne ou un volume de requêtes limité peut orienter les priorités techniques. Elle ne démontre pas que le domaine doit disparaître.

Ce découplage protège la qualité du débat. Une amélioration de consultation des données doit être jugée selon l’usage, le coût et les besoins de la communauté. La survie d’une architecture doit être jugée selon les dépendances, le processus de normalisation, les autorités compétentes et le plan de transition. Confondre les deux aurait permis à une décision de produit de devenir un référendum sur le DNS.

Le même principe s’applique au nettoyage. Une délégation défaillante ne doit pas rester éternellement inscrite par crainte de toucher à l’architecture. Elle ne doit pas non plus disparaître sans horodatage du test, description de l’erreur, tentative de contact, délai de réponse et voie de restauration. La réversibilité distingue l’entretien d’une confiscation silencieuse.

Une correction encore ouverte aux commentaires

Le 25 août est la date immédiate à surveiller. Le document du 17 août est un projet communautaire, non la déclaration finale. Le SG2 n’a pas confirmé l’entrée en vigueur, et aucune suppression individuelle n’est présentée ici comme accomplie.

Cette prudence n’enlève rien à la portée du revirement. En février, une difficulté d’exploitation avait entraîné une question sur l’avenir de tout le système. En août, le RIPE NCC affirme que les 23 anomalies doivent devenir des cas individualisés, tandis qu’une modification d’architecture aurait besoin d’un processus séparé et plus large.

La réunion de septembre peut ainsi produire un résultat modeste mais concret : une procédure pour confirmer, réparer, retirer ou restaurer une délégation. Si une proposition de fermeture revient un jour, elle devra apporter ses propres données sur les usages, les dépendances, le coût de transition et le statut du protocole. Un contrôle DNS peut alerter ce débat ; il ne peut pas le conclure.

Sources