Résumé

  • RFC 3055 définissait une surface de comptage côté serveur pour quatre services PINT, quatre fenêtres temporelles et quatre axes d’analyse.
  • Le mot « réussi » restait une classification de l’agent : il ne prouvait ni la réponse d’une personne, ni l’audibilité d’un contenu, ni la lisibilité d’un fax.

Une demande Internet, une exécution téléphonique

PINT reliait deux mondes sans les confondre. Depuis Internet, une demande pouvait provoquer un appel entre deux parties, l’envoi d’un fax, le retour d’un document stocké dans le réseau téléphonique ou la lecture vocale d’un contenu. L’exécution gardait pourtant une grande partie de ses détails dans le PSTN.

Cette dissociation rendait l’observation difficile. Un serveur pouvait accepter la demande et échouer devant la passerelle. La passerelle pouvait accepter et ne pas achever l’opération téléphonique. Un appel établi ne garantissait pas qu’une personne entende; une session de fax terminée ne certifiait pas une page lisible.

Publié en février 2001 comme Proposed Standard, RFC 3055 définissait une MIB SMIv2 enregistrée par l’IANA sous mib-2 93. Son champ était volontairement étroit : paramètres de performance propres à PINT, non administration des éléments de réseau, non mesure générale de l’hôte ou du réseau. Cette modestie fixait le lieu de l’observateur.

Quatre services et quatre vues

Les services étaient Request-to-Call, Request-to-Fax, Request-to-Fax-Back et Request-to-Hear-Content. Les périodes couvraient trente secondes, quinze minutes, vingt-quatre heures et le temps écoulé depuis le redémarrage.

La table globale comptait réceptions, succès et interruptions, avec des catégories d’échec liées à l’autorisation, au serveur ou à la passerelle. La vue client utilisait une adresse sous forme de chaîne. La vue utilisateur s’indexait sur UserIdName. La vue passerelle rassemblait les résultats par nom de passerelle enregistrée.

Ces vues n’étaient pas quatre témoins autonomes. L’agent tournait sur le serveur PINT, y compris lorsqu’il observait les connexions vers les passerelles. Une convergence pouvait localiser un problème; elle ne créait pas une trace indépendante dans le PSTN ou chez le destinataire.

Qui avait le droit de dire « succès » ?

Les noms SuccessfulCalls paraissent conclusifs. La MIB ne plaçait pourtant aucun observateur près de chaque combiné ou scanner derrière chaque télécopieur. Elle normalisait les objets par lesquels une implémentation exposait sa propre décision.

Acceptation par le serveur, remise à la passerelle, exécution téléphonique, sortie du terminal et résultat utile pour l’être humain sont des reçus distincts. Sans règle d’incrément documentée et sans preuve aval, le compteur ne dépasse pas la couche qui l’alimente.

La bonne lecture n’est donc pas « le compteur ne sert à rien », mais « le compteur doit conserver son périmètre ».

Counter32 exige une histoire de continuité

Les valeurs étaient des Counter32. SMIv2 précise qu’ils augmentent jusqu’à 2^32−1 puis repartent de zéro, et qu’une valeur isolée ne contient généralement aucune information.

Un total de 17 000 n’est pas un débit. Il ne révèle ni charge, ni arrêt, ni reprise, ni remise à zéro. Il faut deux échantillons horodatés et une continuité crédible. RFC 3055 confiait explicitement à l’application consommatrice la gestion du bouclage pour la période « depuis le redémarrage ».

Les fenêtres glissantes soulèvent d’autres questions : alignement des bornes, sondage manqué, horloge de l’agent. La MIB d’applications ultérieure détailla davantage les discontinuités, mais ce progrès ne peut être projeté sur chaque agent PINT historique.

Une ligne absente n’était pas zéro

Les tables par client et utilisateur pouvaient coûter cher. Le texte laissait le vieillissement des lignes à l’implémentation locale et évoquait une future vue top-N. Une absence pouvait donc signifier aucune activité, expiration, détail non implémenté, limite de ressources ou différence d’identifiant.

UserIdName devait aussi rester unique dans l’architecture concernée; l’ajout d’un identifiant client et d’un horodatage était proposé. La clé reflétait une politique d’identité autant qu’un trafic. Lire l’absence comme zéro effaçait cette politique.

Pas de notification native, pas de preuve par le silence

RFC 3055 ne définissait aucun trap. Il renvoyait aux seuils RMON pour repérer, par exemple, des échecs répétés d’authentification ou des appels importuns. Or une alarme RMON dépend d’une variable, d’un intervalle, d’un mode d’échantillonnage, de seuils et d’un événement.

Le silence peut signifier qu’aucun seuil n’a été franchi. Il peut aussi signifier qu’aucune alarme n’a été configurée, que la table était inaccessible ou que l’événement n’a pas été livré. L’absence d’alerte n’est pas un reçu de santé.

Lire pouvait déjà être sensible

Seul le contact administratif était modifiable et aucun objet n’était créable. Pourtant, GET pouvait révéler un identifiant client, des relations de passerelle, un volume commercial ou une concentration d’échecs. RFC 3055 avertissait que SNMPv1 ne fournissait pas un environnement sûr et recommandait USM et VACM.

Le chiffrement du réseau ne décidait pas quel principal pouvait lire quel objet. RFC 3414 et RFC 3415 ont ensuite remplacé les textes cités, sans prouver leur déploiement dans un système PINT.

Sources

Lu Heng n’a ni rédigé ni approuvé RFC 3055. Ses textes ne servent ici que de grille d’analyse déclarée. Le H. Lu cité dans RFC 2458 n’est pas assimilé à cet auteur sans preuve d’identité indépendante.