Résumé

  • AFPUB-2026-GEN-002-DRAFT01 affiche Version 3.0 et reste Under Discussion ; AFRINIC-37 n’a trouvé aucun rough consensus et l’a renvoyé à RPD.
  • L’évaluation décrit cinq contrôles automatisables : contacts WHOIS, abuse-c, objets de route, couverture RPKI pertinente et DNS inverse, ainsi que six états horodatés.
  • La durée de persistance et les règles de suspension de service, révocation ou fermeture seraient définies plus tard par le personnel.
  • La visibilité précoce peut faciliter la correction, mais un signal ne doit jamais devenir une sanction qui se prouve elle-même.

Commencer par aider à corriger

Le meilleur scénario est préventif. Un contact ancien, une boîte abuse-c inactive ou une incohérence de données peut être corrigé avant toute conséquence. L’évaluation recommande d’ailleurs un déploiement par étapes : visibilité, avis, examen humain, puis seulement une éventuelle exécution lorsque systèmes et procédures sont prêts.

Les six exemples — conforme, premier avis, deuxième avis, correction en cours, escalade et clôture — créent une mémoire utile. Mais le projet n’a pas obtenu de consensus et rien ne prouve qu’un tableau d’exécution ait été déployé ou qu’un membre ait été sanctionné.

Un indicateur n’est pas un constat

Chaque contrôle dépend d’une définition, de la provenance des données, de leur fraîcheur et d’un taux d’erreur. L’absence de RPKI peut signifier que l’obligation ne s’applique pas ; une incohérence de route peut être transitoire. L’évaluation elle-même sépare les indicateurs objectifs des jugements qualitatifs sur le besoin, l’utilisation et les documents.

Le Detection-to-Remedy Ledger doit enregistrer l’obligation exacte, la source, la version de la requête, l’horodatage, le résultat, la preuve visible au membre et le chemin de correction. Ensuite seulement un réviseur humain identifié peut formuler un constat motivé.

Les transitions décisives manquent

Quel avis démarre la période persistante ? Combien de rappels, par quel canal et avec quelle preuve de réception ? Qui accepte la correction ? Qu’est-ce qui transforme « escalade » en suspension, révocation ou fermeture ? Draft01 renvoie ces décisions économiques à une procédure écrite ultérieurement par le personnel.

Cette procédure doit avoir une version, une autorité d’approbation, une date d’effet et un historique. Chaque avis doit joindre obligation, preuve et raisons ; chaque correction doit recevoir un critère d’acceptation et un reçu de clôture.

Un lien RSA mort n’établit pas le contrat actuel

La page des accords et le PDF RSA 2018 cités renvoyaient 404 lors de la vérification. Une archive conserve les dix pages du document AFRINIC de 2018, avec avis, remède, résiliation et appel. C’est une preuve historique, pas la preuve du texte actuellement signé par chaque membre.

Avant toute exécution, AFRINIC doit publier l’emplacement autoritatif et identifier la version contractuelle applicable à chaque membre. La position juridique du personnel sur le rôle du RSA est institutionnelle, non judiciaire, mais elle ne peut être résolue par un lien inaccessible.

Encadrer l’exception

Le Board pourrait prendre des mesures spéciales pour infrastructure stratégique essentielle, catastrophe naturelle, instabilité politique ou autre situation exceptionnelle. Une soupape peut protéger la connectivité, mais les définitions, seuils, conflits, motifs, durée, révision et sortie sont absents.

Heng Lu distingue la continuité d’un registre vérifiable de la punition par un carnet d’adresses privé. Le registre complet sépare signal, constat humain, avis, correction, escalade, sanction, exception et rollback. Aujourd’hui, le seul état prouvé est Draft01, affiché Version 3.0, sans rough consensus, renvoyé à RPD ; aucune mise en œuvre, sanction, faute ou dommage n’est établi.