Summary

  • RFC 9922 define tipos y agrupaciones YANG comunes para ventanas, recurrencias, validación y estado. Deja fuera, de forma expresa, la naturaleza de la acción y la resolución de conflictos; por eso un calendario habilitado no identifica por sí solo a quien conserva la potestad de ejecutarlo.
  • Daniel Kade propone un recibo de autoridad de la ocurrencia: versión y huella del calendario, acción y objetivo, patrocinador institucional, política vigente, principal ejecutor, tiempo y resultado. Es una propuesta editorial para operadores, no un requisito del RFC ni una denuncia sobre un despliegue.

El futuro hereda una instrucción, no necesariamente un mandato

Programar es almacenar una decisión para que produzca efectos después. La separación permite reservar capacidad con antelación, esperar una ventana de mantenimiento y repetir tareas sin presencia humana. Su valor depende precisamente de que el sistema no pregunte desde cero cada vez.

Sin embargo, una instrucción y la autoridad que la sostiene envejecen a ritmos distintos. La expresión temporal puede permanecer intacta mientras cambia el equipo propietario. Una cuenta de servicio puede conservar permisos durante una migración. Un recurso ordinario puede convertirse en crítico. Una política nueva puede estrechar los efectos permitidos.

Cuando llega la siguiente ocurrencia, el planificador sabe que la fecha encaja. Puede saber que la versión almacenada es la última y que no hay choque con otro calendario. No necesariamente sabe si la institución sigue queriendo la acción bajo las condiciones actuales.

No hace falta imaginar a un atacante. Basta con una reorganización legítima y un sistema que conserva lo que se le pidió. El error aparece cuando un cuadro de mando traduce “vigente”, “habilitado” y “sin conflicto” por una palabra mayor: “autorizado”.

La validez de RFC 9922 tiene un significado concreto

RFC 9922 es un documento Standards Track del IETF publicado en marzo de 2026. Su módulo ietf-schedule reúne tipos y agrupaciones reutilizables para programar eventos, políticas, servicios y recursos. Admite ejecuciones únicas, períodos y recurrencias, desde reglas simples hasta una forma inspirada en iCalendar.

El RFC protege su modularidad con límites claros. No presupone qué acción dispara el calendario. La detección y solución de conflictos entre calendarios quedan fuera de alcance. Además, el módulo común no expone por sí solo nodos editables, estado operativo ni RPC: otros módulos incorporan y amplían sus agrupaciones.

Por eso no sería razonable exigirle una teoría única de autorización. Un aviso, una prueba OAM y un cambio destructivo no deben compartir por fuerza la misma aprobación. La responsabilidad nace cuando un módulo consumidor une el tiempo con el efecto.

El campo validity del grupo generic-schedule-params fija la fecha después de la cual un calendario deja de ser válido para comenzar. Una ocurrencia posterior no se ejecuta. También existen límites mínimos y máximos de inicio, un máximo de finalización y una conducta de descarte.

Esa validez es temporal. No contiene el órgano aprobador, la función actual del creador, la versión de la política de acceso ni el efecto de un cambio en el objetivo. Un calendario puede estar dentro de su ventana y fuera de su mandato.

Ver el estado no equivale a ver la autoridad

Los grupos de estado pueden exponer si el calendario está habilitado, deshabilitado, terminado, caducado o en conflicto. Incluyen versión, última actualización, contadores, última y próxima ocurrencia, último fallo y número de fallos. Son datos valiosos para operar.

Pero una versión actual solo identifica la definición que el sistema considera corriente. No prueba quién aprobó esa versión ni si esa aprobación sigue vinculada al propietario presente. La fecha de última actualización no es la fecha de última ratificación. Cero fallos no significa cero ejecuciones improcedentes.

La comparación de RFC 9922 con el antiguo DISMAN-SCHEDULE-MIB hace visible el límite. El cuadro traduce muchos objetos, pero para schedOwner dice “Not Supported”. El mismo RFC señala que los módulos futuros pueden añadir origen y precedencia si varias fuentes alimentan calendarios.

No se puede concluir que las implementaciones carezcan de propietario. Pueden añadirlo y algunas seguramente lo hacen. La conclusión legítima es que la identidad del dueño o patrocinador no forma parte del estado genérico común. Quien necesite demostrarla debe conservarla en la capa donde el calendario adquiere un efecto.

NACM responde en el momento de la petición

RFC 8341 normaliza NACM para restringir operaciones y datos de NETCONF y RESTCONF. Una sesión autenticada aporta un usuario y grupos. El servidor aplica las reglas vigentes al iniciar el procesamiento del mensaje y mantiene esas reglas durante ese mensaje.

NACM puede controlar quién crea, cambia o borra un calendario. También puede proteger acciones y nodos que defina el módulo consumidor. Sería falso presentarlo como una ausencia de autorización.

La pregunta pendiente es temporal: ¿bajo qué principal actúa una ocurrencia meses después? RFC 8341 se refiere a peticiones iniciadas desde sesiones de usuario y distingue ciertos accesos iniciados por el propio servidor. RFC 9922 no obliga a que el disparo futuro herede la sesión original, use una identidad de servicio o solicite una decisión nueva.

Cada opción puede ser correcta en un contexto. Un respaldo recurrente puede pertenecer a la organización y sobrevivir a la rotación del personal. Una operación sobre confianza, rutas o capacidad escasa puede requerir revalidación si cambió el objetivo. El defecto no es escoger una regla; es dejar que una regla implícita decida.

El registro debe distinguir creador, patrocinador institucional, principal técnico y autoridad aprobadora. Convertirlos en un solo nombre de usuario hace frágil tanto la continuidad como la revocación.

El reloj seguro solo demuestra tiempo

RFC 9922 advierte que la programación depende de un tiempo preciso. Una fecha incorrecta puede activar eventos en intervalos equivocados. Las recurrencias muy frecuentes pueden ocultar anomalías o ocupar recursos. La ausencia de registros detallados sobre cada disparo y resultado dificulta reconstruir un incidente.

RFC 3339 define la representación de fechas. RFC 7317 permite configurar zona horaria y NTP en sistemas YANG. RFC 8915 añade Network Time Security: identidad de las partes, autenticación de paquetes, protección frente a repetición y coherencia entre petición y respuesta.

Todo ello permite confiar mejor en que la ejecución ocurrió a la hora declarada. No concede permiso a la acción. Un reloj auténtico puede despertar puntualmente una orden cuyo patrocinador ya no existe. Y una orden legítima puede ejecutarse mal por una hora incorrecta.

La evidencia debe conservar dos cadenas: una para el tiempo y otra para la autoridad. Si ambas se comprimen en “validación correcta”, la investigación posterior no sabrá cuál falló.

Reservar recursos separa aún más decisión y efecto

RFC 8413 estudia la reserva temporal de recursos de ingeniería de tráfico. Un LSP futuro puede calcularse y reservar capacidad antes de establecerse. El marco pide correlacionar la reserva con el futuro LSP para explicar por qué se apartó el recurso, gestionar la prelación y liberar tras una cancelación. La política del operador sigue gobernando el uso y la reoptimización.

RFC 8934 lleva esa idea a PCEP. Una PCE con estado mantiene una base de LSP programados; al inicio, la PCC activa la configuración, y al vencimiento puede retirarla. Solicitud, cálculo, sincronización, activación y eliminación se reparten en el tiempo.

Los RFC no dicen que exista un fallo de autorización. Muestran por qué hace falta nombrarla. La ruta puede seguir siendo factible y la capacidad permanecer reservada mientras una orden comercial se cancela o el servicio cambia de dueño. Cumplir las restricciones de red no demuestra la voluntad institucional presente.

Un recibo para la ocurrencia concreta

La solución editorial no modifica el módulo común. Añade un objeto de evidencia allí donde el calendario se une a una acción significativa. Ese recibo puede emitirse por ocurrencia o cubrir una serie de bajo riesgo delimitada criptográficamente.

Debe enlazar:

  • identificador estable, versión y huella de la definición del calendario;
  • instancia de recurrencia, hora prevista y hora observada;
  • clase de acción y objetivo, con compromisos protegidos para valores sensibles;
  • creador y patrocinador institucional actual;
  • base de autorización inicial y versión vigente de política o delegación;
  • principal de ejecución y resultado actual de permitir o denegar;
  • fuente de tiempo y margen relevante;
  • decisión ante conflicto, precedencia o prelación;
  • compromiso de estado pretendido, observación del estado aplicado y resultado;
  • razón de fallo, cancelación o no ejecución deliberada;
  • enlace de sustitución y corrección.

No es una invitación a pedir aprobación humana en cada minuto. Una autorización firmada puede abarcar una clase de acciones, un conjunto de objetivos, un nivel de riesgo y varias ocurrencias. Debe invalidarse si cambian la versión, el patrocinador, la política, el objetivo o el efecto.

Tampoco exige publicar usuarios, topología o configuración. Una superficie compartida puede mostrar clases institucionales, identificadores de política, huellas, custodios y decisiones; la evidencia sensible permanece protegida.

Las objeciones delimitan la solución

La continuidad importa. Un calendario institucional no debe morir cuando se marcha quien lo creó. El recibo permite transferirlo de forma expresa a un rol duradero, conservando la decisión anterior y la nueva.

El coste también importa. Recalcular reglas complejas en cada recurrencia rápida puede ser inviable. Una concesión temporal en caché es razonable si su alcance, duración e invalidadores son visibles. No es permiso perpetuo por inercia.

Puede haber duplicación: NACM, el orquestador y el sistema de auditoría quizá posean ya los datos. El recibo debe unirlos, no crear otra base completa. La prueba es si un operador independiente puede reconstruir el calendario, la política actual, el principal y el resultado sin depender de conversaciones privadas.

Por último, la genericidad de RFC 9922 es intencional. Precisamente por eso el control pertenece al módulo que conoce la acción. La crítica no va contra el calendario; va contra usar su estado como sustituto de la decisión.

Límites de la evidencia

Las fuentes describen estándares, no despliegues. No demuestran que un proveedor u operador concreto ejecute tareas con autoridad obsoleta. No documentan incidente, explotación, pérdida o incumplimiento. Tampoco demuestran que las implementaciones carezcan de dueño, cuenta de servicio, revisión o registro suficiente.

El recibo no es un mandato del IETF. RFC 9922 es un RFC de consenso con un alcance bien delimitado y remite correctamente los riesgos específicos a los módulos consumidores.

La conclusión es más contenida: un calendario puede seguir vigente en el vocabulario temporal y operativo de RFC 9922 mientras la autoridad de la acción sigue siendo un hecho separado. Si la organización no registra cómo perdura, se transfiere, se reevalúa o se retira esa autoridad, la etiqueta «habilitado» termina prometiendo más de lo que demuestra.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9922/
  5. https://www.rfc-editor.org/rfc/rfc9922.html
  6. https://www.rfc-editor.org/rfc/rfc8341.html
  7. https://www.rfc-editor.org/info/rfc8413/
  8. https://www.rfc-editor.org/rfc/rfc8934.html
  9. https://www.rfc-editor.org/rfc/rfc3339.html
  10. https://www.rfc-editor.org/rfc/rfc7317.html
  11. https://www.rfc-editor.org/rfc/rfc8915.html
  12. https://www.rfc-editor.org/rfc/rfc8342.html
  13. https://www.rfc-editor.org/rfc/rfc7950.html
  14. https://www.rfc-editor.org/rfc/rfc6241.html
  15. https://www.rfc-editor.org/rfc/rfc8040.html