Resumen

  • RFC 3159 exigía que PIB-INDEX designara un único InstanceId y negaba a ese valor cualquier semántica distinta de identificar la instancia de la PRC. Una coordenada inequívoca no era una explicación de política.
  • El significado estaba repartido entre el módulo PIB, la PRC, las convenciones textuales, la categoría de sujeto, el modo de acceso, la unicidad, las referencias, la conformidad y los ciclos de vida de AUGMENTS y EXTENDS.
  • La ejecución pertenecía a recibos posteriores: intercambio COPS-PR, resultado de la transacción, estado del PEP, comportamiento aplicado y resultado de la aplicación. Su posterior condición Historic y el despliegue limitado no borran esta separación.

Dos números diferentes no bastaban para producir dos políticas

Un PDP envía dos Provisioning Instances a un router. Cada atributo funcional coincide: clasificador, acción, umbral y referencia a una cola. Solo difieren los valores de InstanceId.

La base de datos puede mostrar dos filas, pero todavía no sabe si representan dos intenciones. El módulo quizá admita duplicados. Una cláusula de unicidad puede prohibirlos. Una fila puede ser una extensión dispersa cuyo registro base no existe. También pueden pertenecer a almacenes virtuales diferentes. Tras pasar el esquema, el PEP aún puede rechazar la instalación.

SPPI limitó la afirmación del índice. PIB-INDEX contenía un descriptor con sintaxis InstanceId; el valor era un entero sin signo de 32 bits sin otra semántica que identificar una instancia de PRC. Al anexarlo al OID de la definición de fila se obtenía el PRID.

Era una dirección, no una política comprimida. Si una implementación codificaba a escondidas el cliente, la prioridad o la región dentro del número, creaba un segundo esquema fuera del módulo. Una migración podía romper ese significado sin que el validador formal detectara nada.

SPPI heredó herramientas de SMI, pero cambió el vocabulario

La Structure of Policy Provisioning Information, publicada en agosto de 2001, adaptó la SMI de SNMP para escribir módulos PIB. Conservó conocimientos, formas ASN.1 y herramientas conocidas.

Sin embargo, COPS ya llamaba objects a sus elementos de protocolo. Para evitar la colisión, SPPI denominó Provisioning Class o PRC a la tabla y a la definición de fila; Provisioning Instance o PRI a una fila concreta; y atributo a la columna. No ofrecía el equivalente de los objetos escalares de SMI.

MODULE-IDENTITY comunicaba la semántica del módulo. OBJECT-TYPE describía la sintaxis y el significado de PRC y atributos. Las convenciones textuales añadían semántica reutilizable a tipos subyacentes. Los grupos y la conformidad fijaban capacidades mínimas.

Nada de ello convertía el modelo en ejecución. Una PRI podía decodificarse, satisfacer tipos y contener todos los campos obligatorios sin que el PEP la aceptara. Aceptarla tampoco probaba que la conducta del equipo hubiera cambiado.

PIB-INDEX y INDEX cumplían funciones distintas

Una fila base necesitaba PIB-INDEX, salvo cuando heredaba identidad mediante AUGMENTS o EXTENDS. La cláusula designaba un solo atributo InstanceId, normalmente de la misma PRC, aunque no era obligatorio.

La cláusula ordinaria INDEX podía aparecer con otro propósito: la conversión algorítmica de una PIB a una MIB. Confundirlas mezclaba la identidad operativa de una instancia de aprovisionamiento con el índice de una representación administrativa derivada.

Por eso un archivo que conserve únicamente el PRID está incompleto. Debe guardar el módulo y su revisión, la definición de PRC, las convenciones aplicables y el contexto. Sin el diccionario, un OID preciso sigue siendo una dirección huérfana.

Con el diccionario se puede explicar qué significan los campos. Todavía no se puede afirmar que la fila fue instalada.

El significado surgía de varios contratos unidos

La PRC definía los atributos y sus descripciones. Las convenciones textuales daban un significado particular a un entero o una cadena. SUBJECT-CATEGORIES vinculaba el módulo a COPS Client Types concretos o a todos. Un mismo módulo podía residir en más de un almacén virtual.

PIB-ACCESS indicaba la relación permitida. install autorizaba al PDP a instalar instancias. notify obligaba al PEP a comunicar todas las instancias y valores. install-notify combinaba ambos sentidos. report-only no poseía esas características, aunque sus instancias podían aparecer en informes síncronos o asíncronos del PEP.

El PRID no distinguía estos casos. Una fila instalable y una fila de informe podían lucir identificadores igual de estables. Era necesario volver a la definición para saber quién la originaba y qué operación admitía.

Una declaración de conformidad añadía información sobre capacidad mínima, no sobre la presencia de una instancia particular.

La unicidad no era otro nombre para el identificador

UNIQUENESS enumeraba atributos cuyo conjunto de valores no podía repetirse entre instancias de una PRC. El atributo usado por PIB-INDEX no podía formar parte del conjunto.

SPPI separaba así la identidad protocolaria de la identidad por contenido. El número servía para referirse a la fila; los campos de unicidad podían distinguir su significado operativo. Una cláusula vacía admitía dos instancias idénticas en todos los atributos salvo el número.

“ID distinto” no equivale a “política distinta”. Tampoco es seguro fusionar filas de contenido igual: pueden tener referencias, almacenes o ciclos de vida diferentes.

La especificación recomendaba declarar unicidad cuando aportara información, pero no la exigía universalmente. Ante su ausencia, una herramienta no debía inventar una clave natural y atribuírsela al estándar.

Una referencia sin tipo de destino era solo un número

Todo atributo ReferenceId necesitaba PIB-REFERENCES, que nombraba la PRC de la instancia destino. TagReferenceId necesitaba PIB-TAG, que indicaba el atributo usado para formar un conjunto etiquetado en otra PRC.

El primer mecanismo seleccionaba una instancia declarada; el segundo, un conjunto de instancias con un valor de etiqueta común. Los bytes del entero no permitían distinguir la relación.

La instancia 12 de una PRC de colas no era automáticamente la instancia 12 de una PRC de umbrales. Una etiqueta 7 no se volvía global fuera del módulo y del atributo que fijaban su alcance.

Una prueba recuperable debía guardar el atributo de origen, su convención, la PRC destino, las reglas de identidad del destino y la revisión del módulo. Copiar solo el número preservaba la apariencia del enlace y perdía su dirección.

Base, aumento y extensión dispersa tenían vidas diferentes

Cada definición de fila elegía exactamente una relación: PIB-INDEX, AUGMENTS o EXTENDS.

Una PRC con AUGMENTS mantenía correspondencia uno a uno con su base. Heredaba el índice y compartía la existencia: instalar o eliminar la base instalaba o eliminaba también cada aumento.

EXTENDS describía una relación cero-o-uno. La extensión dispersa no podía existir sin la base, pero la base sí podía existir sola. La extensión debía instalarse explícitamente, podía eliminarse antes y desaparecía implícitamente al retirar la base. Si ambas se instalaban juntas, debían viajar en un solo mensaje COPS.

El mismo valor de instancia podía participar en tres regímenes temporales distintos. Restaurar las filas sin recuperar la relación podía crear un registro direccionable que no tenía derecho a existir.

La identidad permite unir registros. El ciclo de vida dice cuándo esa unión es válida. Una fotografía de números coincidentes no sustituye la historia de instalación y retirada.

Una fila válida todavía podía fracasar al instalarse

INSTALL-ERRORS permitía enumerar motivos específicos para rechazar la instalación o eliminación de una PRC. Cada motivo usaba un subcódigo COPS. La ausencia de la cláusula no impedía el fracaso; solo eliminaba el error específico de la PRC.

El límite corta una cadena de inferencias equivocadas. Validar el esquema no demuestra aceptación. Aceptación no demuestra que la transacción terminara. Una transacción terminada no verifica el estado local. La configuración no prueba que el tráfico la haya activado. Y el tráfico esperado no prueba por sí solo el resultado de la aplicación.

COPS-PR aportaba decisiones, errores, finalización, caché y reconciliación después de reconectar. SPPI describía los datos que viajaban. Un protocolo de transacción y un lenguaje de datos se necesitaban mutuamente, pero no eran el mismo recibo.

Un indicador verde debe decir cuál de estos pasos verificó. De otro modo, el éxito sintáctico oculta todos los estados posteriores que siguen siendo desconocidos.

La conformidad medía capacidad, no una ejecución concreta

Los grupos reunían atributos relacionados y MODULE-COMPLIANCE expresaba grupos obligatorios y mínimos de acceso. Una implementación que afirmara conformidad tenía que implementar esas PRC y atributos.

Podía, sin embargo, no tener ninguna instancia instalada. Podía almacenar una instancia sin activar su conducta. Una conducta activa podía no coincidir con tráfico alguno. Capacidad, configuración y resultado eran tres capas.

La frase de seguridad de RFC 3159 también era estrecha: el lenguaje para definir información de aprovisionamiento no tenía por sí mismo impacto de seguridad en Internet. No certificaba las sesiones COPS, la autoridad del PDP, la seguridad del contenido ni la corrección del PEP.

Toda garantía debía quedarse dentro de la capa que realmente describía.

Historic registró un cambio de rumbo, no la inexistencia

RFC 6632 dejó constancia de que COPS-PR no se había desplegado ampliamente. Los operadores consideraban difícil usar su codificación binaria desde lenguajes de scripting habituales para tareas sencillas. Ningún módulo PIB fue aprobado como Proposed Standard y el uso de COPS-PR dejó de recomendarse. RFC 3159 figura hoy como Historic.

Una historia responsable debe contar esa retirada. SPPI no es el sistema dominante actual. Pero despliegue limitado no significa ausencia absoluta, y Historic no borra el documento ni permite inventar el estado de equipos concretos.

La ruta abandonada conserva una idea nítida: dirección, significado, acceso, ciclo de vida, transacción y efecto no son sinónimos. Una API moderna repite el error si presenta un URI estable o una respuesta 200 como prueba de conducta en ejecución.

La adopción determina qué tecnología prosperó. No determina por sí sola qué distinción conceptual sigue siendo útil.

El artefacto duradero era una cadena, no el PRID aislado

Un expediente auditable empieza por el módulo PIB exacto, la revisión, la categoría de sujeto y el almacén virtual. Conserva PRC, convenciones, relación base/aumento/extensión, InstanceId, PRID completo, unicidad, referencias, etiquetas, acceso y perfil de conformidad.

Después conserva la solicitud y decisión COPS-PR, el identificador y resultado de la transacción, errores generales y específicos, contexto de caché o reconexión y estado del PEP antes y después. La observación del tráfico demuestra qué se aplicó. La aplicación evalúa finalmente si el objetivo se cumplió.

El módulo explica los campos. El PRID designa la instancia. El protocolo prueba el intercambio. El equipo prueba la instalación. El tráfico prueba la aplicación y el sistema usuario prueba el resultado.

El índice de RFC 3159 era útil porque se negaba a fingir que contenía toda esa cadena. Nombraba la fila; no fabricaba el desenlace.

Fuentes