Résumé

  • RFC 1239 réattribua cinq racines MIB du préfixe expérimental 1.3.6.1.3 aux branches standards mib-2 et transmission.
  • Le motif était opérationnel : renuméroter tard obligeait les fournisseurs à réviser leurs implémentations, risquait des problèmes sur le terrain et décourageait les essais précoces.
  • La table officielle prouve la décision d’attribution. Elle ne prouve ni la date ni l’étendue de la migration d’un agent, d’un gestionnaire ou d’une série de mesures.

Le numéro avait quitté la marge du document

RFC 1239 ne définit pas un nouveau protocole. Il corrige une pratique de normalisation. Les MIB en développement recevaient d’abord un arc sous le préfixe expérimental. L’arc standard n’arrivait qu’au stade Full Standard. Le passage d’un statut à l’autre pouvait donc forcer les fournisseurs à réviser leurs produits alors même que les définitions n’avaient probablement pas changé sur le fond.

Dans la SMI de RFC 1155, l’OID est le nom administratif d’un type d’objet. Il devient la clé envoyée par le gestionnaire, reconnue par l’agent, enregistrée dans les collecteurs et liée à un libellé dans les tableaux de bord. Déplacer la racine déplace tous ses descendants. La sémantique peut sembler familière ; l’adresse réellement interrogée ne l’est plus.

Le mémo relève deux coûts. Une réattribution tardive pouvait provoquer des difficultés opérationnelles à un moment indésirable. L’attente d’un numéro stable pouvait aussi retarder l’implémentation jusqu’au stade final, donc priver le travail normatif du retour d’expérience recherché. Sa solution était de réserver tôt les arcs standards et de les conserver pendant la progression du texte.

Les fiches du RFC Editor et du Datatracker classent aujourd’hui le document comme Historic et Legacy. Ce statut décrit la place actuelle du mémo ; il ne dit pas quel OID un équipement concret a servi en 1991, ni lequel il sert maintenant.

Cinq correspondances, cinq migrations possibles

RFC 1229 avait installé les extensions génériques d’interface sous 1.3.6.1.3.6. RFC 1239 leur attribua 1.3.6.1.2.1.12. Le sujet restait le même, mais la racine passait d’experimental 6 à mib-2 12.

Les quatre autres racines gagnèrent la branche transmission. Le Token Bus de RFC 1230 passa d’experimental 7 à transmission 8. Le Token Ring de RFC 1231 passa de 4 à 9. Les objets DS1 de RFC 1232 passèrent de 2 à 18 ; les objets DS3 de RFC 1233, de 15 à 30.

Cette liste ne constitue pas un protocole de transition. Elle ne fixe aucun délai, ne crée aucun alias, ne demande pas un double service, ne décrit pas la conversion des historiques et ne négocie aucune capacité. Elle établit l’ancien et le nouveau nom. Entre les deux se trouvent les versions d’agents, les logiciels de gestion, les configurations, les fenêtres de maintenance et les décisions locales de conservation.

L’autorité du registre ne remplace pas l’observation

Le registre SMI de l’IANA conserve aujourd’hui GenericIF 12 et les valeurs de transmission 8, 9, 18 et 30. Plusieurs lignes renvoient désormais à des RFC ultérieurs, car les définitions ont continué leur histoire après 1991. Le registre présent répond donc à « quel numéro fait autorité maintenant ? ». RFC 1239 répond à « quelle réattribution fut décidée alors ? ».

Aucun des deux ne répond seul à « qu’a fait cet agent à cet instant ? ». L’échec d’une requête sur le nouvel OID peut signaler une ancienne implémentation, une absence d’objet, un refus d’accès, une panne ou une erreur de requête. Une réponse sur l’ancien OID établit une réponse observée, non l’échec universel de la norme. L’absence dans une branche n’est pas une preuve sur l’autre.

La même prudence vaut pour les séries temporelles. Un collecteur peut conserver le même libellé humain tout en changeant de clé numérique. Fusionner les deux séries peut masquer un changement de version ou de sémantique ; les séparer peut inventer une rupture purement administrative. RFC 1239 ne documente aucun incident de ce type. Il montre pourquoi le journal de migration doit exister.

Un dossier probant conserverait l’OID exact, l’agent et le gestionnaire concernés, leurs versions, l’heure des requêtes, les réponses, le contexte d’accès et la règle de rapprochement des données. Même une période de double prise en charge doit être observée, non déduite de la table officielle.

Enfin, un identifiant stable ne fige pas le sens. Un texte ultérieur peut modifier le statut, l’accès ou l’interprétation sous la même racine. RFC 1239 cherchait à stabiliser l’adresse pour éviter une dette inutile ; il n’a jamais promis l’immobilité du contenu. Continuité numérique et continuité sémantique restent deux affirmations.

Sources