Resumen

  • RFC 3318 permitía usar * en una combinación de roles de política para abarcar interfaces con los roles obligatorios y cualquier cantidad de roles adicionales.
  • El comodín no decidía precedencia: el PDP debía resolver políticas incompatibles y el PEP tenía que rechazar el conflicto restante, no improvisar una mezcla local.

La duplicación deja huellas visibles. Ocupa archivos, mensajes y revisiones. La superposición puede permanecer oculta hasta el momento de instalar una política. En RFC 3318, ambos problemas nacían de la misma decisión de diseño: describir interfaces por roles reutilizables y permitir que un asterisco ampliara el conjunto de coincidencias.

El documento definía el Framework Policy Information Base común a clientes COPS-PR. Un Policy Decision Point elegía la política; un Policy Enforcement Point representaba el equipo que debía aceptarla; SPPI proporcionaba las clases e instancias de la base de información. El Framework PIB añadía roles, conjuntos de capacidades, versiones de estado, limitaciones y errores compartidos.

Un rol era una cadena asociada a una función de interfaz: finance, manager, interfaz troncal o cortafuegos. Una interfaz podía tener varios. Una instancia de política llevaba una RoleCombination y se aplicaba según la relación entre esa combinación y el conjunto de la interfaz. Así, el servidor central no necesitaba conocer el identificador local de cada puerto.

La escritura del conjunto era canónica. La comparación distinguía mayúsculas y minúsculas; los roles se ordenaban lexicográficamente por ASCII. a+b era válido y b+a no representaba otro conjunto, sino una forma inválida del mismo. La combinación sin roles era null. La disciplina eliminaba una ambigüedad de formato antes de evaluar la política.

El asterisco servía para comprimir. En clases install o install-notify, *+a+b coincidía con una interfaz que incluyera a y b, además de cero o más roles distintos. * no podía ser un rol real notificado por la interfaz ni un comodín dentro de un nombre. RFC 3318 muestra que *+b+e+g coincide con a+b+c+e+f+g.

Si tres interfaces compartían A y B pero añadían R1, R2 y R3, una sola política *+A+B podía cubrirlas. El PDP evitaba tres copias y el operador expresaba directamente la propiedad común.

Sin embargo, coincidir no equivale a tener prioridad. Una interfaz podía satisfacer varias combinaciones con comodín. Dos políticas podían coexistir si actuaban sobre aspectos independientes; también podían asignar valores incompatibles al mismo tratamiento. El patrón sólo demostraba aplicabilidad, no resolvía la colisión.

RFC 3318 situaba la responsabilidad en el PDP. El controlador debía intentar resolver el conflicto antes de enviar las políticas. Si varias políticas incompatibles llegaban al PEP, por error del PDP o por una restricción específica del dispositivo, el PEP debía rechazar la instalación y devolver un error. La ejecución no recibía permiso para convertirse silenciosamente en decisión.

El ejemplo de finanzas y gerencia dejaba el límite aún más claro. Al principio, dos interfaces podían tener finance y otra manager. Cuando una persona de finanzas ascendía, aparecía la combinación finance+manager. El PDP podía declarar preferente la política de gerencia o crear una tercera, por ejemplo con DSCP 7 para gerentes financieros. Incluso si repetía una política anterior, debía descargar una respuesta explícita para la nueva combinación.

El PEP no debía construirla a partir de las dos antiguas. Esa síntesis parecería eficiente, pero fabricantes distintos podrían combinar entradas idénticas de maneras diferentes. El PDP perdería la capacidad de justificar el resultado. Un rechazo crea un recibo investigable; una fusión automática crea deriva con apariencia de éxito.

El cambio de roles también era una transición, no un instante. El PEP declaraba sus asociaciones en un estado completo. El PDP podía modificarlas mediante una decisión no solicitada. Tras procesarla con éxito, el PEP enviaba primero el informe positivo y después estados completos actualizados para sus contextos. Si fallaba, sólo debía informar del fallo. El PDP no debía asumir el nuevo estado antes del éxito.

Durante ese intervalo todavía podían llegar decisiones basadas en los roles anteriores. Por tanto, una nueva etiqueta no demostraba que todas las políticas dependientes estuvieran recalculadas. RFC 3084 definía la secuencia de petición, decisión e informe; RFC 3159 daba forma a las PIB, PRC y PRI. La evidencia debía separar asignación de rol, aceptación, estado refrescado, política nueva y tratamiento real del tráfico.

La seguridad de transporte tampoco aportaba precedencia. RFC 3318 advertía que todo lo configurable podía configurarse mal con efectos graves. Autenticar el mensaje demuestra su emisor y cifrarlo protege su contenido. Ninguna de esas operaciones decide si finance debe dominar a manager.

En 2016, el IESG trasladó RFC 3318, COPS-PR y SPPI a Historic, citando despliegue limitado y el cambio del trabajo de gestión hacia NETCONF y YANG. Esa historia impide presentar el mecanismo como práctica extendida. Aun así, conserva una lección: reducir texto no reduce la obligación de nombrar al árbitro.

El asterisco economizaba políticas, no decisiones. RFC 3318 dejó la interpretación de la superposición en el PDP y convirtió el rechazo del PEP en el límite seguro cuando el resultado central seguía siendo incoherente.

Fuentes: RFC 3318, RFC 3084, RFC 3159 y el cambio de estado del IESG de 2016.