Résumé

  • La RFC 3737 transfère à IANA la responsabilité des futures racines de modules MIB RMON, jusque-là consignées par le groupe de travail, sans déplacer les OID existants.
  • La frontière est précise : IANA attribue la racine MODULE-IDENTITY sous rmon ; les auteurs et éditeurs du module attribuent les identifiants ordinaires à l’intérieur de celui-ci.

Une liste qui fonctionnait, jusqu’aux corrections tardives

Les MIB de surveillance à distance s’étaient accumulées sous le nœud rmon de l’arbre MIB-II, 1.3.6.1.2.1.16. Le groupe RMONMIB tenait sa propre liste d’attributions aux nouveaux modules. La RFC 3737 ne présente pas cette organisation comme un échec : elle indique qu’elle avait plutôt bien fonctionné. Mais des erreurs avaient dû être corrigées tardivement et quelques attributions étaient devenues obsolètes. La pratique différait aussi du processus habituel, où un module MIB sur la voie des standards reçoit sa racine lors de la publication de la RFC.

Le tableau de la RFC rend l’héritage visible. Les premières entrées désignent des groupes d’objets comme statistics, history, alarm et capture ; les numéros suivants identifient des racines MODULE-IDENTITY, des valeurs disponibles, des réservations et une attribution obsolète. L’arbre n’était pas une suite propre d’objets d’un seul type. La RFC reconnaît que certaines premières affectations ne sont pas logiques et qu’elles ne peuvent pas être modifiées. La solution change le gardien des décisions futures, pas les numéros du passé.

IANA reçoit la racine, pas le module entier

La RFC 3737 a versé le registre existant dans le registre SMI Numbers et demandé à IANA d’en assurer la maintenance. Désormais, IANA n’attribue sous rmon que les racines MODULE-IDENTITY. À l’intérieur du module, ses auteurs ou éditeurs continuent d’attribuer les OID ordinaires selon les procédures MIB habituelles. Selon la RFC 2434 alors en vigueur, une nouvelle racine exigeait une action de normalisation ; IANA attribuait le numéro au moment de la publication de la RFC.

La distinction est importante. Une racine est un point partagé de l’espace de noms où deux modules pourraient entrer en collision. Une fois sa racine attribuée, la structure interne peut être organisée dans le module sans demander au registre RMON de numéroter chaque objet. La procédure centralise la frontière sensible aux collisions et laisse la conception interne aux spécifications.

La page IANA SMI Numbers ultérieure montre toujours l’arbre rmon, avec des références désormais liées à la RFC 4502, une valeur disponible, une entrée de module obsolète et des réservations. C’est un état daté du registre, pas la preuve qu’un module est implanté ou déployé. Une racine enregistrée, une MIB implémentée et une observation de surveillance sont trois justificatifs différents. La RFC 3737 change qui consigne la prochaine racine ; la présence dans le registre ne prouve pas l’exécution.

Sources