Résumé

  • La RFC 3159 imposait à PIB-INDEX de désigner un unique InstanceId, auquel elle ne reconnaissait aucune sémantique autre que l’identification de l’instance de PRC. Une adresse exacte ne décrivait pas l’intention de politique.
  • Le sens provenait du module PIB, des définitions de PRC et des conventions textuelles, de la catégorie de sujet, du mode d’accès, des contraintes d’unicité et de référence, de la conformité et des cycles de vie distincts de AUGMENTS et EXTENDS.
  • L’exécution exigeait une chaîne ultérieure : échange COPS-PR, résultat de transaction, état du PEP, comportement effectivement imposé et résultat applicatif. Le statut Historic et l’adoption limitée n’effacent pas cette frontière entre nommer et prouver.

Un numéro différent ne crée pas une intention différente

Supposons que le PDP transmette deux Provisioning Instances à un routeur. Tous les attributs fonctionnels sont identiques : même filtre, même action, même seuil, même file référencée. Les seules valeurs différentes sont les identifiants d’instance.

L’interface d’administration affichera deux lignes. Cette observation ne permet pas encore de parler de deux politiques. Le module peut autoriser des contenus dupliqués, une clause d’unicité peut au contraire les interdire, l’une des lignes peut être une extension sparse dépendant d’une base absente, ou les deux peuvent appartenir à des magasins virtuels différents. Le PEP peut aussi refuser l’installation après validation du schéma.

SPPI bornait précisément ce que l’identifiant affirmait. PIB-INDEX contenait un seul descripteur de type InstanceId. Sa valeur, fondée sur un entier non signé de 32 bits, ne portait aucun sens au-delà de l’identification de l’instance. Ajoutée à l’OID de la définition de ligne, elle formait l’adresse de la PRI.

Une adresse peut être exacte sans être une explication. Si une application encode clandestinement la priorité, le client ou la région dans le numéro, elle crée un deuxième schéma invisible. La renumérotation ou la migration peuvent alors détruire un sens que le validateur officiel ne connaissait même pas.

SPPI reprenait les outils de la SMI, pas toutes ses catégories

Publiée en août 2001, la Structure of Policy Provisioning Information adaptait la SMI de SNMP à l’écriture des Policy Information Bases. Le choix permettait de réutiliser l’expérience ASN.1, les conventions et les outils existants.

Mais le mot « objet » était déjà employé par COPS pour ses éléments de protocole. SPPI rebaptisa donc la table et sa définition de ligne Provisioning Class, ou PRC. Une ligne instanciée devint une Provisioning Instance, ou PRI, et une colonne un attribut. L’équivalent des objets scalaires de la SMI ne fut pas retenu.

MODULE-IDENTITY portait la sémantique générale du module. OBJECT-TYPE décrivait les PRC et leurs attributs. Les conventions textuelles associaient une sémantique spécifique à des types réutilisables. Les groupes d’objets et déclarations de conformité définissaient un minimum d’implémentation.

Cette rigueur formelle ne constituait pas une preuve d’exécution. Une PRI peut être bien typée, complète et décodable sans avoir été acceptée. Un équipement peut l’accepter sans l’appliquer correctement. L’application peut enfin ne jamais rencontrer le trafic auquel la règle était destinée.

PIB-INDEX localisait ; INDEX servait une autre transformation

Une ligne de base devait porter un PIB-INDEX, sauf si elle héritait son identité par AUGMENTS ou EXTENDS. Le descripteur désignait un attribut InstanceId, généralement mais pas obligatoirement défini dans la même PRC.

La RFC permettait aussi un INDEX ordinaire dans certains cas. Celui-ci servait uniquement à la conversion algorithmique d’une PIB en MIB. Confondre les deux aurait mélangé l’adresse d’une instance de provisionnement avec l’indexation d’une représentation de gestion dérivée.

Un journal durable ne peut donc conserver le seul PRID. Il lui faut le module et sa révision, la PRC, les conventions textuelles et le contexte dans lequel l’OID a été interprété. Sans ce dictionnaire, la précision numérique devient trompeuse.

Même accompagné de son schéma, le PRID ne dit que quelle instance est visée et ce que ses champs peuvent signifier. Il ne dit pas que cette instance est installée.

Le sens naissait d’un ensemble de contrats

SPPI distribuait délibérément la sémantique. La PRC énumérait les attributs et leurs descriptions. Une convention textuelle transformait un type élémentaire en donnée dotée d’un sens partagé. SUBJECT-CATEGORIES reliait le module à des COPS Client Types nommés, ou à l’ensemble des catégories. Le même module pouvait exister dans plusieurs magasins virtuels.

PIB-ACCESS précisait la circulation permise. install autorisait le PDP à installer une instance dans le PEP. notify obligeait le PEP à communiquer au PDP toutes les instances et leurs valeurs. install-notify réunissait les deux fonctions. report-only n’était ni installable ni notifiable de cette façon, mais pouvait apparaître dans les rapports du PEP.

Rien de cela n’était visible dans le nombre. Une ligne installable et une ligne réservée au compte rendu pouvaient posséder des identifiants tout aussi stables. Le sens exigeait de rejoindre l’adresse avec sa définition.

La conformité ajoutait un autre renseignement : les capacités minimales déclarées. Elle ne transformait pas une capacité de classe en reçu pour une instance active.

L’unicité ne se réduisait pas à l’identité protocolaire

La clause UNIQUENESS énumérait les attributs dont l’ensemble de valeurs devait être unique entre instances d’une même PRC. L’attribut utilisé par PIB-INDEX en était exclu.

La séparation était volontaire. Le numéro permettait au protocole de référencer une ligne ; l’ensemble d’unicité permettait de distinguer son contenu pertinent. Avec une clause vide, deux instances pouvaient partager tous leurs attributs sauf l’identifiant.

Deux ID différents ne prouvent donc pas deux contenus différents. Deux contenus égaux n’autorisent pas non plus une fusion automatique, car le cycle de vie, les références ou le magasin peuvent différer.

La RFC recommandait UNIQUENESS lorsqu’elle apportait une information utile, mais ne l’imposait pas partout. En son absence, un logiciel ne devait pas inventer une clé naturelle puis présenter cette convention locale comme une règle du module.

Une référence devait conserver le type de sa destination

Tout attribut de type ReferenceId exigeait PIB-REFERENCES, qui nommait la PRC contenant l’instance cible. Un TagReferenceId exigeait PIB-TAG, qui identifiait l’attribut de tag utilisé pour sélectionner un ensemble d’instances dans une autre PRC.

Un mécanisme ressemblait à une référence vers une ligne déterminée ; l’autre formait un ensemble à partir d’une valeur commune. Le même entier ne permettait pas d’en déduire la relation.

L’instance 12 d’une PRC de files d’attente n’est pas l’instance 12 d’une PRC de seuils. Le tag 7 n’est pas un groupe universel hors du module et de l’attribut qui lui donnent sa portée. Copier uniquement le nombre conserve l’apparence du lien et perd sa destination.

La preuve doit donc contenir l’attribut source, sa convention, la PRC cible déclarée, les règles d’identité de cette cible et la version du module.

Une base, une augmentation et une extension sparse ne vivaient pas de la même façon

Chaque définition de ligne choisissait une seule relation : son propre PIB-INDEX, AUGMENTS ou EXTENDS.

Une ligne AUGMENTS avait une relation univoque avec sa base, réutilisait son identité et partageait son existence. Installer ou supprimer l’instance de base installait ou supprimait les augmentations correspondantes.

Une ligne EXTENDS était sparse. Elle ne pouvait pas exister sans sa base, mais sa base pouvait exister sans elle. Son installation devait être explicite. Elle pouvait être supprimée séparément ou disparaître implicitement avec la base. Si base et extension étaient installées ensemble, elles devaient figurer dans un même message COPS.

Un identifiant identique peut donc appartenir à trois formes de vie différentes. Une restauration qui ne récupère que les lignes peut créer une extension orpheline : adressable, mais contraire à son contrat d’existence.

L’identité permet de joindre des enregistrements. Le cycle de vie établit si cette jointure était valide à un instant donné. Une photographie ne remplace pas l’historique d’installation et de retrait.

Une ligne valide pouvait être refusée

INSTALL-ERRORS permettait à une PRC d’énumérer des raisons particulières de refuser une installation ou un retrait. Chaque raison recevait un sous-code COPS. Pourtant, l’absence de cette clause ne garantissait rien : l’opération pouvait toujours échouer, simplement sans erreur propre à la PRC.

La conséquence opérationnelle est nette. Validation du schéma, acceptation du message, achèvement de la transaction, état local de l’équipement, application effective et résultat métier sont des reçus successifs.

COPS-PR organisait la transmission, les décisions, les erreurs, la validation ou l’abandon, l’état en cache et la reconnexion. SPPI décrivait les données transportées. Les deux mécanismes se complétaient sans se confondre.

Un tableau de bord qui n’affiche qu’un voyant vert doit donc indiquer à quelle étape il se rapporte. Sinon, le premier succès syntaxique absorbe toutes les inconnues ultérieures.

La conformité était une capacité, pas une exécution particulière

Les groupes d’objets rassemblaient des attributs liés, et MODULE-COMPLIANCE exprimait les groupes obligatoires ainsi que certaines exigences minimales de syntaxe ou d’accès. Une implémentation revendiquant cette conformité devait connaître les attributs et PRC concernés.

Elle pouvait pourtant ne contenir aucune PRI de cette classe. Elle pouvait stocker une PRI sans activer son effet. Une règle active pouvait ne rencontrer aucun paquet. Capacité, configuration et résultat sont trois états différents.

La section de sécurité de la RFC 3159 était tout aussi bornée : le langage servant à définir l’information de provisionnement n’avait pas, en lui-même, d’impact de sécurité sur Internet. Elle ne certifiait ni la session COPS, ni l’autorité du PDP, ni le contenu de la politique, ni l’implémentation du PEP.

Une preuve ne doit jamais étendre son domaine silencieusement.

Le statut Historic décrit une trajectoire, pas une inexistence

La RFC 6632 nota plus tard que COPS-PR n’avait pas été largement déployé. Les opérateurs jugeaient son codage binaire peu commode pour les scripts de configuration simples. Aucun module PIB ne fut approuvé comme Proposed Standard et l’usage de COPS-PR ne fut plus recommandé. La RFC 3159 est désormais Historic.

Cette chronologie doit accompagner toute analyse honnête. SPPI n’est pas la méthode dominante de configuration contemporaine. Mais « peu déployé » ne signifie pas « jamais implémenté », et Historic ne supprime pas la valeur documentaire de l’architecture.

Le chemin abandonné laisse une frontière durable : adresse, sens, droit d’accès, relation d’existence, transaction et effet ne sont pas interchangeables. Une API moderne peut répéter exactement l’erreur si elle transforme un URI de ressource ou une réponse HTTP réussie en preuve d’exécution.

La popularité mesure l’adoption. Elle ne mesure pas, à elle seule, la précision d’une leçon de conception.

L’artefact durable était la chaîne, non le seul PRID

Un dossier vérifiable commence par le module PIB exact, sa révision, la catégorie de sujet et le magasin virtuel. Il conserve la PRC, les conventions textuelles, la relation de base ou d’extension, l’InstanceId, le PRID complet, les contraintes d’unicité et de référence, le mode d’accès et le profil de conformité.

Il poursuit avec la requête et la décision COPS-PR, l’identifiant de transaction, le résultat d’installation ou de retrait, les erreurs, le contexte de cache ou de reconnexion et l’état du PEP avant et après. Une observation du plan de données établit ensuite ce qui fut effectivement imposé. L’application décide enfin si le but fut atteint.

Le module explique les champs. Le PRID désigne l’instance. Le protocole atteste l’échange. L’état du dispositif atteste l’installation. Le trafic atteste l’application, et l’application atteste l’utilité.

L’index de la RFC 3159 était fiable parce qu’il ne prétendait pas remplacer toute cette chaîne. Il nommait la ligne ; il ne fabriquait pas son résultat.

Sources