Résumé

  • RFC 1243 réunissait ports, routes, zones, services et compteurs AppleTalk dans une même MIB, mais imposait déjà de lire la provenance et l’état avant de prendre une ligne visible pour une réalité opérationnelle.
  • RFC 1742 modifia ensuite plusieurs accès en lecture/écriture et ajouta les distinctions entre source, valeur par défaut et valeur courante : la mutabilité était donc une responsabilité révisable, non la preuve d’un changement accompli.

Imaginons trois ports affichant le même numéro de réseau. Pour le premier, le numéro a été saisi. Pour le deuxième, il a été déduit de l’observation du réseau. Pour le troisième, l’équipement l’a choisi au hasard afin de démarrer. Les octets coïncident ; leur histoire, elle, ne coïncide pas. C’est cette différence que RFC 1243 conserva dans la MIB AppleTalk de juillet 1991.

Le document répartissait les objets entre LLAP, AARP, ATPort, DDP, RTMP, KIP, ZIP, NBP et ATEcho. Le découpage suivait les couches et les mécanismes de la suite AppleTalk. Lorsqu’un groupe s’appliquait à une implémentation, l’agent devait fournir l’ensemble du groupe. Cela décrivait une conformité de modèle, pas l’état d’un réseau particulier.

La table ATPort rend la nuance tangible. Une ligne décrivait une connexion logique : type du port, plage réseau, adresse, état, zone et interface physique associée. Plusieurs de ces champs étaient en lecture-écriture. Deux champs voisins, atportNetConfig et atportZoneConfig, étaient cependant en lecture seule et qualifiaient l’origine de la configuration.

Leur vocabulaire était précis : configured pour une configuration explicite, garnered pour une valeur supposée après inspection du réseau, guessed pour une configuration aléatoire, unconfigured en l’absence de configuration. Une console qui n’enregistrait que la valeur effaçait donc une partie décisive de la preuve. Elle ne pouvait plus distinguer une intention administrative d’une adaptation locale.

L’état de la ligne comptait tout autant. atportStatus pouvait être opérationnel, non configuré, éteint ou invalide. Écrire invalid dissociait le mappage, mais la suppression matérielle de la ligne restait propre à l’implémentation. Le RFC prévenait alors le gestionnaire : une table pouvait encore livrer une entrée qui n’était plus utilisée. La présence n’était pas l’activité.

Le même motif apparaissait dans le routage. RTMP exposait une plage, un prochain saut, un type de réseau, un port, un nombre de sauts et un état. Dans RFC 1243, la plupart de ces valeurs étaient modifiables. L’état séparé passait de bon à suspect, en voie de dégradation puis mauvais. Une ligne invalidée pouvait demeurer visible. KIP distinguait de son côté une route configurée, apprise ou invalide, puis précisait si son information devait être partagée. Origine, validité locale et propagation formaient trois dimensions.

ZIP associait plages réseau et noms de zone. NBP décrivait les services enregistrés sur l’entité par nom, type et zone. Les champs principaux étaient modifiables ; des états séparés commandaient l’invalidation. Là encore, un inventaire construit par simple énumération aurait mélangé état courant et traces conservées.

Les compteurs n’échappaient pas à la limite. ATEcho comptait les demandes reçues et les réponses envoyées par l’agent. Ces totaux ne reliaient pas une demande à sa réponse, ne désignaient pas le pair et ne prouvaient ni parcours ni succès pour un utilisateur. La section sécurité de RFC 1243 indiquait d’ailleurs que ces questions n’étaient pas traitées.

En 1995, la frontière s’est déplacée

RFC 1742, publié en janvier 1995, remplaça RFC 1243. La nouvelle MIB AppleTalk II ajouta des groupes et des compteurs, mais son geste le plus instructif fut de réviser l’accès aux objets existants.

atportNetConfig et atportZoneConfig passèrent de la lecture seule à la lecture-écriture. Dans le sens opposé, les plages, prochain saut, type, port et nombre de sauts RTMP passèrent de la lecture-écriture à la lecture seule. Le nom et les plages de zone ZIP devinrent eux aussi non modifiables par ce canal. « Route » ou « zone » ne possédait donc pas une mutabilité naturelle ; le groupe de travail redéfinissait ce que le gestionnaire proposait et ce que l’agent rapportait.

Le successeur enrichit aussi la provenance. atportNetFrom et atportZoneFrom indiquaient l’origine des informations. L’ancienne zone fut renommée atportZoneDefault, à côté d’une atportCurrentZone distincte. La valeur souhaitée et la valeur en cours pouvaient enfin être conservées sans se masquer. Pour NBP, le texte suggérait à l’agent de réenregistrer le service lorsqu’un nom, un type ou une zone changeait : il nommait l’action attendue sans prétendre que l’écriture en prouvait l’achèvement.

L’instrumentation évolua avec elle. La nouvelle MIB ajouta recherches et succès AARP, suppressions et débordements de routes RTMP, échecs d’enregistrement NBP et compteurs par port. Elle déprécia aussi des compteurs LLAP qui faisaient double emploi avec MIB-II. Un compteur ajouté ou retiré change le périmètre de mesure ; la publication du RFC ne prouve pas que les agents et collecteurs furent mis à niveau au même instant.

Les deux textes racontent ainsi une histoire plus subtile qu’un progrès linéaire. Une MIB est un contrat versionné de commande et d’observation. Pour savoir ce qui s’est réellement produit, il faudrait encore joindre la version du module, l’objet et son instance, la valeur, son origine, l’état de la ligne, l’auteur authentifié de la demande, la réponse, la persistance, l’observation du protocole et l’effet du service.

Les RFC ne fournissent pas ce registre. Ils montrent pourquoi son absence est dangereuse.

Sources et limites

Les sources principales sont RFC 1243, AppleTalk Management Information Base, et RFC 1742, AppleTalk Management Information Base II. Elles établissent les définitions, accès, états et modifications documentées. Elles ne prouvent aucune implémentation nommée, identité, autorisation, écriture acceptée, route active, zone courante, inscription réussie, livraison, part de déploiement ou conséquence pour un usager.