Résumé

  • La RFC 3060 a normalisé un modèle d’information réutilisable — groupes, règles, conditions, actions et associations — mais a explicitement laissé aux implémentations l’algorithme qui convertit ces attributs en résultat.
  • PCIM pouvait représenter des priorités et préciser si l’ordre d’exécution était obligatoire ou recommandé ; cela n’en faisait pas un moteur commun. La RFC 3460 a ensuite fait évoluer le modèle et introduit des stratégies de décision, sans démontrer que les équipements appliquaient les politiques de façon identique.

Une règle se transporte mieux que son interprétation

Deux équipements peuvent recevoir des objets de politique qui portent les mêmes noms sans aboutir au même comportement. Leurs capacités locales, leurs extensions ou leur code d’évaluation peuvent différer. Cette distinction est au cœur de la RFC 3060, « Policy Core Information Model — Version 1 », publiée en février 2001.

PCIM décrit une structure d’information : des classes représentent les éléments de politique et des classes d’association relient leurs instances. Une PolicyRule associe des conditions à des actions. Des PolicyGroups regroupent des règles ou d’autres groupes. Les conditions peuvent prendre la forme d’un OU de ET ou d’un ET de OU, et une condition individuelle peut être niée. Des priorités permettent de distinguer une règle générale d’une exception.

Le texte donne un exemple parlant : le trafic du groupe « ingénierie » peut relever d’un service Bronze, tandis qu’une règle plus prioritaire attribue un service Gold à une personne précise du même groupe. Le modèle peut exprimer ce chevauchement et la priorité. Il faut encore qu’un système concret évalue les conditions, choisisse la règle applicable puis traduise l’action en configuration propre à l’équipement.

Une déclaration, sans algorithme commun

La RFC qualifie son approche de déclarative, mais en précise aussitôt la portée. Le modèle définit des entités et des attributs ; il ne définit ni l’algorithme qui produit un résultat, ni la suite d’étapes que doit suivre le traitement. Il permet d’indiquer un ordre souhaité des actions, obligatoire ou simplement recommandé. Il n’impose pas pour autant une procédure d’évaluation universelle.

Cette frontière compte dès qu’une politique sort du schéma. Que signifie une condition absente ? Comment une extension inconnue est-elle traitée ? Quel ordre choisir si deux règles se contredisent ? Que faire quand les capacités des équipements diffèrent ? PCIM prévoyait des classes d’extension, notamment pour les conditions et actions propres à un fournisseur. Cette souplesse facilitait l’adaptation, mais laissait aussi de la place à des sémantiques locales derrière une structure commune.

Les auteurs exposent eux-mêmes leurs arbitrages : rendre les définitions compréhensibles et diagnostiquables tout en gardant un traitement assez simple pour une variété d’équipements. Ils reconnaissent que l’expérience collective de la gestion par politique était encore limitée et déconseillent de viser l’exhaustivité. Leur préférence allait à un noyau commun pour les besoins alors présents, tels que VPN et QoS, avec une évolution ultérieure guidée par l’expérience.

Le document indique aussi que des travaux ultérieurs décriraient le passage vers des implémentations concrètes, avec, par exemple, un annuaire LDAPv3. C’est une indication de frontière : un modèle d’information peut alimenter une implémentation, mais ne prouve pas qu’un annuaire, un serveur de décision ou un routeur l’ait adopté.

Le cadre voisin avait d’autres fonctions

La RFC 2753 distinguait le Policy Decision Point (PDP), où la décision est prise, du Policy Enforcement Point (PEP), où elle est appliquée. La RFC 2748 définissait ensuite COPS, un protocole client-serveur d’échange de requêtes et de décisions entre ces rôles. La RFC 3084 décrivait un usage de COPS pour provisionner des Policy Information Bases. Ces spécifications voisines n’étaient pas PCIM : protocole de transport, données de provisioning et schéma d’information répondent à des questions différentes.

En pratique, chaque étape appelle une preuve distincte. Un dépôt peut contenir une règle ; un PDP peut l’évaluer ; un PEP peut recevoir une décision ; un routeur peut installer une configuration. La présence d’un objet conforme au modèle ne dit pas quelle version le terminal a consommée, comment il a compris une extension, ni quel effet le trafic a subi.

La version suivante a enrichi le modèle

En janvier 2003, la RFC 3460 a mis à jour PCIM. Elle ajoutait de nouveaux éléments, en dépréciait et remplaçait d’autres, modifiait la représentation des priorités et introduisait des stratégies de décision définies par l’administrateur. C’est une évolution réelle du modèle d’information et la preuve que son vocabulaire restait amendable.

Elle ne prouve toutefois pas que deux équipements exécutaient la même stratégie de la même manière. Décrire un champ de stratégie dit ce qui peut être représenté, pas comment un moteur l’interprète ni ce qu’un routeur installe. La RFC 3198 rappelle d’ailleurs que le passage d’objectifs métier à des paramètres propres aux équipements peut exiger des informations supplémentaires sur le réseau et les capacités locales.

La conclusion historique doit rester mesurée : la RFC 3060 cherchait à rendre les informations de politique réutilisables dans un environnement hétérogène. Elle indiquait aussi ce que le socle ne normalisait pas : l’algorithme commun. Les RFC établissent l’existence du modèle et de son évolution ; elles ne prouvent ni le nombre de produits qui l’ont mis en œuvre, ni un résultat opérationnel uniforme.

Une évaluation sérieuse suit donc toute la chaîne : quelles classes et extensions ? Quelle version le PDP a-t-il évaluée ? Comment a-t-il départagé des règles concurrentes ? Que le PEP a-t-il installé ? Quel traitement les paquets ont-ils réellement reçu ? Une description partagée peut améliorer la coordination ; elle n’est pas, à elle seule, un reçu d’interopérabilité des résultats.

Sources