Résumé

  • En mai 2015, Alain Durand a organisé cinq années de statistiques de l’IANA autour de trois communautés opérationnelles: noms de domaine, ressources de numérotation et paramètres de protocole.
  • Ses graphiques rendent visibles des évolutions distinctes: l’arrivée des nouveaux gTLD accompagne davantage de délégations, les demandes de ressources de numérotation restent globalement stables sur la période et les PEN dominent les demandes de paramètres de protocole.
  • Un nombre de requêtes renseigne sur l’activité, mais ne suffit pas à établir la charge de travail, la qualité du traitement, le risque d’une erreur ou le pouvoir de décider la politique applicable.

Comprendre le service depuis l’intérieur

Le billet publié par Alain Durand le 27 mai 2015 part d’un constat personnel précis. Il avait passé plus de vingt ans dans l’IETF, présidé des groupes de travail et contribué à des RFC. Il connaissait donc les registres de l’IANA par leur usage dans les travaux techniques. Après avoir rejoint l’ICANN quelques mois plus tôt, il reconnaissait pourtant ne pas bien connaître leur fonctionnement interne. Une partie de son rôle consistait alors à soutenir la transition de la supervision de l’IANA.

Il a entrepris de consulter cinq années de statistiques d’usage disponibles. L’exercice n’était ni un audit indépendant, ni une prévision de charge, ni une proposition de gouvernance. Il répondait à une question plus opérationnelle: quels services les communautés utilisaient-elles, et comment cette demande évoluait-elle? En publiant les séries séparément, Durand a transformé une fonction souvent décrite au singulier en plusieurs flux observables.

L’IANA maintenait, selon son billet, plus de 2 800 registres pour trois communautés: les noms de domaine, les ressources de numérotation et les paramètres de protocole, dont ceux utilisés par l’IETF. Ce total décrit l’étendue du catalogue, pas 2 800 services également actifs ou de charge identique. Un registre peut recevoir peu de changements et exiger néanmoins une obligation de continuité importante. À l’inverse, une longue série de modifications routinières peut gonfler les volumes sans signifier que chaque dossier est complexe.

La distinction est utile aux responsables comme aux lecteurs. Une mise à jour de coordonnées n’est pas la même opération qu’une délégation de domaine. Une allocation de ressources de numérotation applique une politique convenue dans la communauté concernée. Une attribution de paramètre de protocole suit ses procédures propres. Un opérateur commun peut effectuer ces tâches, mais le nom « IANA » ne les transforme pas en unité de travail homogène.

Trois séries, trois histoires

Dans la partie consacrée aux noms, Durand distingue les délégations et redélégations de changements plus ordinaires, comme des mises à jour de contacts, de serveurs de noms ou d’enregistrements DS. Le graphique des nouveaux gTLD fait apparaître une hausse sensible des délégations et redélégations après le lancement du programme. Ce changement indique que l’environnement de la demande a évolué; il ne signifie pas que l’opérateur a créé le programme ni que le nombre de demandes mesure à lui seul sa valeur sociale.

La série des ressources de numérotation raconte autre chose. Durand signale de grandes demandes de blocs IPv6 avant 2010, puis l’épuisement en 2011 du stock IANA d’adresses IPv4 unicast non allouées. Quelques blocs retournés ont ensuite été redistribués aux registres régionaux selon la politique mondiale. Sur son graphique de cinq ans, les requêtes de cette communauté restent globalement stables. Cela porte sur les demandes reçues par l’opérateur, pas sur l’ensemble du trafic Internet, l’utilisation des adresses ni l’intensité de la pénurie IPv4.

Les paramètres de protocole formaient le groupe le plus vaste de registres. Parmi les registres IETF, les Private Enterprise Numbers (PEN) étaient les plus sollicités, notamment pour la configuration de bases MIB SNMP. La série PEN était si importante qu’elle aurait rendu les autres courbes difficiles à lire. Durand l’a donc représentée séparément. Ce choix graphique rend les catégories moins bruyantes, mais rappelle aussi que l’échelle et les axes participent à l’interprétation d’un graphique.

Dans sa vue d’ensemble, il place les trois familles côte à côte et utilise un axe secondaire pour les délégations de ccTLD et de gTLD. Il décrit une activité globale assez prévisible, à l’exception de l’effet des nouveaux gTLD; les demandes de numérotation restent relativement plates, tandis que les demandes de paramètres augmentent après une période plus calme autour du milieu de 2012. Ce résumé est utile comme observation des flux. Il ne prouve ni que les différentes catégories sont comparables, ni que la série est un indicateur suffisant de capacité.

Compter n’est pas évaluer

Une demande par mois est une unité claire, mais étroite. Elle dit qu’un événement a été enregistré; elle ne dit pas combien de validations, de clarifications, de personnes ou d’heures ont été nécessaires. Elle ne mesure pas davantage le délai, l’exactitude du résultat, la gravité d’une correction, les systèmes dépendants ou l’autorité habilitée à contester une décision.

Un rapport contractuel du même mois fournissait déjà d’autres repères. Pour les changements courants de domaines délégués, la cible était que 80 % soient traités en 21 jours. Le résultat annoncé était de 86,1 % dans le délai et de 100 % d’exactitude. Les mesures relatives aux numéros suivaient des éléments distincts, notamment l’application correcte de la politique, les délais de mise à jour des registres, les demandes de clarification et la transparence. Aucun dossier de ressources de numérotation n’avait été achevé durant ce mois de rapport.

Ces indicateurs ne répondent pas à la même question que le volume mensuel: les réunir sous un score unique ferait perdre ce que chacun mesure.

La même prudence s’applique à l’autorité. Pour les paramètres relevant de l’IETF, le RFC 2860 prévoit que l’IANA applique les critères et procédures des RFC et sollicite l’avis de l’IESG en cas de doute technique. L’opérateur exécute une règle dans un cadre donné; le compteur de demandes n’est pas la source de cette règle. Les RFC 3901, 3363 et 4472 montrent par ailleurs la contribution technique de Durand à des sujets DNS et IPv6, avec des coauteurs et éditeurs. Ils éclairent son expérience, sans autoriser à lui attribuer seul ces textes.

En mars 2016, la proposition finale du groupe de coordination de la transition a maintenu des responsabilités de politique et de supervision distinctes pour les communautés des noms, des numéros et des paramètres de protocole. Le conseil de l’ICANN a accepté cette proposition le même jour. Les documents ne disent pas que l’étude de Durand a causé ou décidé cette architecture. On peut reconnaître l’intérêt de son travail de mesure sans lui attribuer le résultat collectif de la transition.

Ce que les données rendent possible

La contribution observable de Durand est plus circonscrite, et plus défendable: il a rendu le mélange de demandes plus intelligible au moment où l’organisation cherchait à expliquer l’étendue de ses fonctions. Sa démarche relie l’expérience d’un utilisateur technique à une question de fonctionnement interne. Elle ne transforme pas les statistiques en verdict sur l’importance d’une communauté.

Pour évaluer un service, les lecteurs doivent donc prolonger la carte par d’autres questions: quelle catégorie a été comptée? Quelle règle s’applique? Qui a fixé cette règle? Combien de temps le dossier a-t-il attendu sous le contrôle de l’opérateur, et combien de temps dépendait d’un demandeur ou d’un expert? Le résultat était-il exact, visible et corrigeable? Qui peut examiner un désaccord et imposer une mesure corrective?

L’index de performance actuel de l’IANA présente encore des surfaces distinctes pour les accords de niveau de service des noms, les ressources de numérotation, les attributions IETF et le mainteneur de la zone racine. Cette organisation actuelle n’établit pas une filiation directe avec le graphique de 2015. Elle montre toutefois pourquoi un seul total ne constitue pas nécessairement le meilleur tableau de bord: les obligations et les publics diffèrent selon le service.

Une hausse du volume peut justifier une analyse de capacité; elle ne déclenche pas automatiquement une modification de politique. Une courbe stable ne signifie pas qu’un service est sans risque. Les demandes rares peuvent avoir des conséquences importantes, tandis qu’une série fréquente peut être composée d’opérations standardisées. La bonne unité d’analyse dépend de la décision envisagée.

Le billet de Durand est donc le plus utile comme carte, pas comme mandat. Il montre où les demandes arrivaient et comment leur composition changeait. Pour savoir si le service était rapide, exact, résilient ou correctement supervisé, il faut d’autres mesures et nommer l’institution compétente. La visibilité rend la discussion plus concrète; elle ne remplace ni le jugement ni l’autorité.

Sources