Résumé

  • L’ASO AC a transmis la version 3 au NRO EC le 28 juillet 2026 ; le NRO NC a publié le projet recommandé, le redline et le rapport justificatif le 1er septembre 2026.
  • La section 1.3 permet l’applicabilité avant l’existence de procédures communes, tandis que chaque RIR conserve une marge sur son approche de conformité.
  • L’analyse BTW recommande un registre public, disposition par disposition, sans traiter l’étiquette FINAL DRAFT comme une preuve d’adoption.

Le texte se trouve à un moment de transition. Le NRO NC, également appelé ASO AC, a achevé la version 3 et l’a transmise au NRO EC le 28 juillet 2026. Le NRO EC a indiqué qu’il l’examinerait, coordonnerait son travail avec ICANN et les RIR, puis publierait un calendrier actualisé. Le 1er septembre, le NRO NC a publié le projet recommandé, un redline comparé à la version 2 et un rapport justificatif.

Le document se décrit comme un « FINAL DRAFT ». Cela décrit l’étape de rédaction, et non une adoption achevée par ICANN et tous les RIR, le remplacement actuel de l’ICP-2 ou un effet juridique avant l’adoption formelle. À la date du gel du 7 septembre 2026, le jeu de sources gelé ne contient ni calendrier daté de la dernière phase ni catalogue public d’Implementation Procedures adoptées.

La section 1.3 constitue le point de tension opérationnel. Les RIR et ICANN peuvent élaborer et adopter conjointement des Implementation Procedures publiées fixant des exigences minimales. Elles ne peuvent contredire ou remplacer le document. Mais, en l’absence de procédure adoptée, chaque RIR conserve une latitude pour définir son approche de conformité, tandis que l’absence de procédure n’empêche pas l’application de la disposition.

Cette combinaison crée un déficit de responsabilité sans démontrer une faute ou une non-conformité actuelle. Une règle substantielle peut être applicable alors que la méthode commune d’application reste indéterminée. La section 1.4 renvoie aux procédures pertinentes de l’entité qui décide, avec une possibilité de contestation ou d’appel lorsqu’elle s’applique. Pour les membres d’AFRINIC et les Resource Holders, la question pratique est donc de savoir qui décide, selon quelle procédure publiée, avec quelles preuves et quel recours.

L’analyse BTW recommande que le NRO EC publie un registre de mise en œuvre avec son calendrier actualisé. Il devrait séparer six états : adoption du document ; rédaction de la procédure ; adoption de la procédure ; mise en œuvre locale par le RIR ; préparation à l’audit ; usage réel. Un statut vert dans une colonne ne doit pas signifier que les autres sont achevées.

Le registre devrait inclure : disposition ; responsable de la procédure ; état de la consultation ; état de l’approbation ; date d’effet ; état de la mise en œuvre locale ; dépendance ; lien vers la preuve ; exception ; voie de contestation.

Les lignes suggérées, dérivées de la surface de contrôle du projet, couvrent les déclarations de conflits d’intérêts, les règles de publication et de caviardage, les tests de matérialité, la réception des Compliance Reviews, les audits quinquennaux, les Rehabilitation Plans, la qualification d’un Temporary Emergency Operator, le transfert des données de continuité, les Transition Plans et les procédures d’appel.

Il s’agit de lignes de suivi recommandées, et non de l’affirmation qu’une procédure distincte serait juridiquement requise pour chaque élément. Elles rendraient visible la différence entre une règle inscrite dans le document et un contrôle publié, déployé, testé et utilisé.

Le projet modifie notamment le seuil de reconnaissance à deux tiers des RIR, ajoute la déclaration des conflits d’intérêts et la publication des évaluations et motifs, et attribue à ICANN des fonctions précises d’examen et de décision. Il prévoit un audit régulier au moins tous les cinq ans. Une Compliance Review peut être demandée par la majorité des autres RIR, par le RIR lui-même ou par le moindre de 15 % ou 1 000 de ses membres, sous réserve de critères de matérialité et de mesures correctives préalables.

La chaîne prévue est la suivante : si un Audit ou une Compliance Review constate une non-conformité, ICANN publie ses conclusions et peut travailler avec les RIR à un Rehabilitation Plan, puis vérifie et publie le résultat de la remédiation. Le RIR concerné peut lui-même déclencher un Temporary Emergency Continuity Arrangement pour ses propres services. ICANN et les deux tiers des autres RIR peuvent aussi en déclencher ou en renouveler un après discussion, lorsque cela est raisonnablement possible. L’arrangement est limité à 90 jours, sauf renouvellement, et impose des obligations de publication et de participation de la communauté.

La dereconnaissance est un dernier recours, après une possibilité raisonnable de remédier à la non-conformité matérielle ; les deux tiers des autres RIR doivent soutenir la proposition avant qu’ICANN puisse l’approuver.

Le NRO NC affirme que la version 3 répond aux principales préoccupations de la consultation. C’est le point de vue de l’organe rédacteur, non une constatation indépendante. Son rapport présente la Compliance Review comme plus légère et plus rapide qu’un audit complet et indique que ses garde-fous visent à prévenir les abus. Il explique aussi que le nouveau seuil d’urgence doit accélérer la réponse, tandis que la limite de 90 jours doit empêcher le temporaire de devenir la norme.

Les sources gelées ne disent pas quelles procédures existent déjà en privé ou sont en cours de rédaction interne. Elles ne disent pas non plus comment seront interprétés « material », « reasonable », « promptly » ou « where reasonably possible », ni qui sera l’auditeur ou le Temporary Emergency Operator. Ces inconnues doivent rester des inconnues dans le registre.