Resumen

  • El código 314, el Application-Id 16777243 y el AVP Policy-Data permiten reconocer el diálogo definido por RFC 5224. Son coordenadas del protocolo, no certificados de autoridad sobre cada decisión.
  • La documentación OMA admite una ruta de evaluación sin ejecución. La decisión puede volver al recurso solicitante para que este decida cómo actuar, o PEEM puede ejecutar por su cuenta. Esas rutas no dejan el mismo tipo de recibo.
  • La operación debe conservar una cadena desde la solicitud y sus datos hasta la decisión, la recepción por el ejecutor, la instalación, la activación, la sustitución posterior y el efecto observado.

El verbo cambió en el tablero

La trampa aparece en una traducción operacional aparentemente inocente. El motor devuelve una respuesta válida. El registro técnico dice decision returned. El tablero ejecutivo muestra policy enforced. Entre ambas frases falta un hecho, pero la interfaz lo convierte en estilo.

Pensemos en una prueba de mesa. Un recurso envía PDR a las 11:00. Recibe PDA a las 11:00:01, con identificadores correlacionados y resultado de éxito. El adaptador de ejecución está reiniciándose. Cuando vuelve, encuentra una regla local posterior y descarta la decisión. El protocolo funcionó; la política no llegó a gobernar el recurso. Marcar el intercambio como fallo sería inexacto. Marcar la acción como cumplida también.

RFC 5224 ocupa un lugar muy específico. Es Informational y resume el uso de códigos Diameter para una aplicación OMA: PDR/PDA comparten el código 314; Policy-Data usa el código 1 en el espacio del proveedor; la aplicación tiene el identificador 16777243. Los detalles normativos de la interfaz están en PEM-1, no en el breve registro del RFC.

Esa arquitectura documental evita una confusión frecuente. Registrar un lenguaje común no equivale a observar la conducta de una implementación. La especificación dice cómo nombrar y transportar. La producción debe demostrar quién decidió, con qué datos, quién ejecutó y qué cambió.

Identificar la aplicación no identifica al principal

El registro AAA de IANA conserva las asignaciones. OMA usa Vendor-Id 30079 y anuncia compatibilidad mediante los AVP de capacidades Diameter. Esa coordinación evita colisiones y permite que los extremos seleccionen la gramática adecuada.

Sin embargo, un código no responde si el nodo tiene mandato para decidir sobre la cuenta, el flujo o el servicio concreto. La ruta de realm puede ser correcta y la autoridad empresarial, incorrecta. El host puede estar autenticado y usar datos obsoletos. El software puede soportar la aplicación y no estar habilitado para una categoría de recursos.

RFC 5224 hereda la seguridad de RFC 3588. RFC 6733 actualiza el protocolo base y su protección entre pares. Autenticar el par y proteger el mensaje es indispensable; no certifica la procedencia interna de Policy-Data ni convierte la identidad de transporte en autoridad de negocio.

Por eso el inventario de confianza debería guardar tres relaciones: par criptográfico, autorización para la aplicación y delegación para la decisión específica. Si la organización las ata en una sola configuración, debe conservar la versión y vigencia de ese vínculo.

El BLOB oculta variedad, no incertidumbre

La especificación PEM-1 usa plantillas y BLOB porque las políticas consumen datos heterogéneos. Un template estándar o personalizado ofrece estructura, pero no aporta por sí mismo calidad factual.

El identificador de template ayuda a decodificar. La versión distingue revisiones. Ninguno demuestra que un saldo fue leído después de la última transacción, que una ubicación corresponde al sujeto actual o que un atributo personalizado significa lo mismo en ambos dominios.

La propia especificación deja fuera de alcance cómo se publican las opciones compatibles, cómo PEEM procesa las entradas y cómo el recurso solicitante procesa las salidas. No es una invitación a suponer conducta uniforme. Es una frontera de responsabilidad.

La solicitud debería conservar los bytes originales, el template y su versión, el sujeto y el recurso, la política elegida, la fuente y hora de cada dato, y cualquier llamada delegada. Un resultado sin esa procedencia puede ser reproducible como mensaje y opaco como decisión.

Evaluar y ejecutar no son sinónimos

PEM-1 usa “procesamiento de política” para dos posibilidades: evaluación; o evaluación más ejecución. La arquitectura PEEM expone las consecuencias.

En una ruta, PEEM devuelve una decisión al recurso solicitante. Ese recurso conserva el control sobre su interpretación y sus acciones. En otra, PEEM ejecuta y quizá no devuelve valor. Existe además un modelo explícito de evaluación sin acciones ni enforcement por parte de PEEM.

La división PV/PF refuerza la lectura. PV evalúa y devuelve un resultado. PF realiza la acción consecuente y puede depender de terceros. Aunque ambos vivan en el mismo proceso, siguen existiendo dos estados verificables: decisión producida y acción realizada.

El modelo IETF coincide. RFC 2753 sitúa las decisiones en el PDP y la ejecución en el PEP. RFC 3198 define enforcement como ejecución de una decisión. Que un PEP deba obedecer es una norma; que haya obedecido en este caso es una afirmación empírica.

El éxito tiene capas

En una respuesta pueden convivir al menos tres resultados. Diameter informa un resultado de protocolo mediante Result-Code o Experimental-Result. Experimental-Result es un contenedor de códigos del proveedor, no una medición experimental del efecto.

PEM-1 incorpora Output Status, con un statusCode obligatorio sobre el procesamiento o un error. Y la política produce una decisión o datos que el receptor interpreta. Los tres pueden ser correctos mientras el actuador sigue sin cambiar.

Una taxonomía honesta separa: transportado, aceptado, evaluado, decisión devuelta, recibido por el ejecutor, instalado, activo, efecto observado, sustituido y revertido. El producto puede resumir para un lector, pero debe permitir bajar hasta el estado exacto.

El binding añade otra pista: usa NO_STATE_MAINTAINED. El servidor no conserva estado de sesión Diameter ni espera terminación. Una respuesta correlaciona un intercambio puntual; no constituye un arrendamiento duradero de política ni conserva su historia de reemplazo.

No mezclar esta frontera con fiabilidad o capacidad

RFC 3539 estudia watchdog, failover, solicitudes pendientes y duplicados en AAA. Es crucial para saber si una petición se perdió, se repitió o se procesó más de una vez. No demuestra que el resultado se ejecutó.

RFC 2989 formula requisitos de capacidad AAA. Poder transportar autorización no prueba una acción concreta. RFC 7683 trata sobrecarga y RFC 4006 define un estado de control de crédito mucho más específico. Son contextos útiles para recordar que transporte, capacidad, estado de aplicación y resultado de servicio son dimensiones distintas.

La evidencia mínima se escribe allí donde cambia el control: solicitud y ruta; par seguro; política, sujeto e inputs; decisión y dependencias; estados de protocolo y PEEM separados; ejecutor designado; recibo del ejecutor; objetivo, estado anterior e instalación; readback y activación; reemplazos; medición del efecto; conciliación final.

No se debe corregir la historia hacia atrás. Si una decisión fue reemplazada, sigue siendo cierto que se devolvió. Si la instalación falló, se añade ese fallo; no se finge que el motor nunca respondió. Este modelo preserva causalidad y permite compensación.

La doctrina de Lu Heng ofrece la prueba editorial: un registro describe una capa de realidad, no adquiere soberanía sobre las siguientes. El código clasifica el mensaje. La respuesta registra una decisión. Solo los sistemas en ejecución crean y muestran el estado posterior. Dar a cada evidencia un nombre estrecho es una forma de control, no una limitación semántica.

Fuentes

  1. RFC 5224
  2. RFC 5224 en texto plano
  3. RFC 5224 en IETF Datatracker
  4. Estado de RFC 5224
  5. Historial de RFC 5224
  6. Erratas de RFC 5224
  7. RFC 3588
  8. RFC 6733
  9. RFC 3539
  10. RFC 2989
  11. RFC 2753
  12. RFC 2748
  13. RFC 3198
  14. RFC 3084
  15. RFC 2903
  16. RFC 2904
  17. RFC 4006
  18. RFC 7683
  19. RFC 5234
  20. Parámetros AAA de IANA
  21. Especificación técnica OMA PEM-1
  22. Arquitectura OMA PEEM
  23. Requisitos OMA PEEM
  24. Registro OMA de AVP privados
  25. Lu Heng — Capas de realidad y poder simbólico
  26. Lu Heng — Primacía del código en ejecución
  27. Lu Heng — El problema de agencia