Resumen

  • RFC 3060 normalizó un modelo reutilizable de información de políticas: grupos, reglas, condiciones, acciones y asociaciones. El algoritmo que convierte esos atributos en un resultado quedó expresamente fuera del modelo común.
  • PCIM podía representar prioridades y marcar el orden de acciones como obligatorio o recomendado, pero no era un motor de ejecución compartido. RFC 3460 amplió después el modelo y añadió estrategias de decisión; ninguno de los documentos demuestra que los equipos aplicaran políticas de manera idéntica.

Una regla puede ser legible en dos equipos y significar algo distinto

Dos routers pueden recibir objetos con los mismos nombres y, aun así, comportarse de manera diferente. Sus capacidades, extensiones o rutinas de evaluación local pueden no coincidir. RFC 3060, el modelo Policy Core Information Model (PCIM), publicado en febrero de 2001, permite ver dónde se separaban la descripción y la ejecución.

PCIM describía relaciones entre datos de política. Una PolicyRule unía condiciones con acciones. Los PolicyGroups agrupaban reglas o grupos; la prioridad podía distinguir una regla general de una excepción. Las condiciones podían formularse como una combinación OR de AND, o AND de OR, y podían negarse en forma individual. Era una gramática de objetos para expresar qué elementos se relacionaban y en qué circunstancias se esperaba que una regla aplicara.

El RFC ilustra el solapamiento con una política de calidad de servicio: el tráfico de un grupo de ingeniería recibe servicio Bronze, pero una excepción de mayor prioridad da servicio Gold al tráfico de una persona concreta del grupo. El modelo puede guardar las dos condiciones y la prioridad. El sistema que lo ejecuta todavía debe evaluar los datos, resolver el conflicto y traducir la acción elegida a controles específicos del dispositivo.

Declarativo no significa automático

El RFC llama declarativo al estilo de PCIM y explica de inmediato qué no implica. El modelo contiene entidades y atributos; no define el algoritmo que genera el resultado ni una secuencia obligatoria de pasos. Sí puede señalar el orden deseado de las acciones y si es vinculante o solo recomendado. No prescribe por ello una máquina de políticas universal.

La diferencia aparece ante los casos difíciles: ¿qué ocurre con una condición ausente?, ¿cómo se trata una extensión que el equipo desconoce?, ¿quién decide entre reglas incompatibles?, ¿qué pasa si dos routers tienen capacidades distintas? PCIM incluía mecanismos de extensión para condiciones y acciones específicas de proveedores. Esa apertura permitía adaptar el modelo, aunque también podía dejar semánticas locales dentro de una estructura común.

Los autores hacen explícito el motivo del límite. Querían que las políticas fueran comprensibles para las personas y, al mismo tiempo, sencillas de procesar para equipos diversos. Reconocieron que aún había poca experiencia colectiva en la gestión basada en políticas y que intentar cubrirlo todo aumentaría la complejidad. Propusieron un núcleo común para necesidades de entonces como VPN y QoS, con evolución posterior a medida que crecieran la experiencia y los requisitos.

El documento también dice que otros trabajos definirían mappings hacia implementaciones concretas, por ejemplo, directorios accesibles por LDAPv3. Esa previsión distingue el modelo de la implementación: PCIM podía servir de base para un camino técnico, pero su publicación no prueba que algún directorio, PDP o router lo adoptara.

Decisión, comunicación y datos eran capas distintas

RFC 2753 separaba el Policy Decision Point (PDP), que toma la decisión, del Policy Enforcement Point (PEP), que la aplica. RFC 2748 definió COPS para intercambiar solicitudes y decisiones entre esos componentes. RFC 3084 describió un uso de COPS para aprovisionar Policy Information Bases. Aunque están relacionados, no son PCIM: el esquema de información, el protocolo de comunicación y el modelo de aprovisionamiento resuelven problemas diferentes.

Por eso hacen falta comprobantes por etapa. Puede existir una regla en un repositorio, haber sido evaluada por el PDP, enviada al PEP y aceptada por un router. Cada hecho es distinto. Encontrar un objeto que siga el esquema no revela qué versión consumió el equipo, si entendió una extensión, qué decisión tomó ni qué tratamiento recibieron los paquetes.

El modelo posterior cambió la representación

RFC 3460 actualizó PCIM en enero de 2003. Incorporó elementos, deprecó y sustituyó otros, modificó la representación de prioridades e introdujo estrategias de decisión definidas por administradores. Es evidencia de evolución del modelo y de que las estructuras comunes podían revisarse.

No es prueba de que varios dispositivos ejecutaran esas estrategias igual. Un campo de estrategia expresa lo que puede representarse; no demuestra cómo lo interpreta cada PDP ni qué configuración acepta cada PEP. RFC 3198 señala que pasar de objetivos de negocio a parámetros específicos de dispositivos puede requerir información externa sobre la red y sus capacidades.

La afirmación histórica debe limitarse a lo que muestran los documentos: RFC 3060 intentó hacer reutilizables los datos de política en entornos heterogéneos, pero no definió un algoritmo común. Las RFC establecen el modelo y su revisión posterior; no indican cuántos proveedores lo implementaron ni si sus resultados fueron interoperables en redes reales.

La evaluación debe seguir toda la cadena: clases y extensiones presentes, versión interpretada por el PDP, regla seleccionada, orden aplicado, decisión enviada, configuración instalada y efecto en el tráfico. Un esquema compartido ayuda a coordinar conceptos; no es un recibo de resultados compartidos.

Fuentes