Resumen

  • draft-ietf-netconf-yp-transport-capabilities-07 permite descubrir los transportes, codificaciones y protocolos de seguridad que admite un servidor de notificaciones YANG, antes del despliegue o durante la ejecución.
  • El catálogo orienta la elección, pero no prueba que la terna exacta esté habilitada ahora, que el receptor sea alcanzable y esté autorizado, que establish-subscription sea aceptado ni que haya entrega.
  • La información de implementación y la lectura del servidor activo tienen procedencias y relojes distintos. Una automatización debe conservar esa diferencia.
  • Un recibo de decisión de capacidad a suscripción puede unir observación, selección, política, petición, respuesta y alternativa. Es una propuesta editorial, no un campo del borrador.

El color verde borra demasiadas preguntas

La revisión 07 de YANG Notification Transport Capabilities aborda una necesidad sensata. Antes de pedir una corriente de notificaciones, un sistema de gestión debería saber qué mecanismos entiende el equipo. El modelo amplía las capacidades de sistema del RFC 9196 con una entrada por transporte y listas de formatos de codificación y protocolos de seguridad.

El ejemplo agrupa HTTPS con XML y JSON y con TLS 1.2 y TLS 1.3. En otra entrada, UDP-notif aparece con JSON y CBOR y con DTLS 1.2 y DTLS 1.3. La estructura permite descartar opciones ajenas al publicador y preparar mejor la solicitud.

El problema aparece cuando una interfaz comprime la respuesta en un indicador verde. «Admite notificaciones» no dice qué formato fue seleccionado, cuál pasó la política de seguridad, de dónde salió la información, qué identidad actuó, a qué receptor apuntó, si el servidor aceptó la petición o si llegó un mensaje.

La revisión 07 se publicó el 17 de agosto de 2026. Datatracker registraba una actualización el 8 de septiembre, fecha límite de comentarios de la última llamada del IETF anunciada el 25 de agosto. Al cierre de esta investigación, el 9 de septiembre, seguía siendo un Internet-Draft activo destinado a Proposed Standard, enviado al IESG y en espera de la actuación del director de área. No era RFC ni aprobación definitiva.

Una capacidad puede vivir en dos tiempos

El RFC 9196 permite ofrecer la misma familia de datos por dos vías. El fabricante puede publicar un archivo de datos de instancia YANG durante la implementación, sin depender de un nodo encendido. El servidor en funcionamiento puede exponer su estado mediante NETCONF o RESTCONF.

La fuente previa ayuda a diseñadores de NMS, integradores y compradores. Describe lo que una implementación o línea de producto puede ofrecer. La lectura en vivo sirve a aplicaciones impulsadas por modelos y puede reflejar licencias, límites de hardware o cambios posteriores. El RFC señala de forma explícita que la información de ejecución permite comprobar si lo comunicado antes coincide con lo realmente implementado.

No hay contradicción automática si los resultados difieren. Un catálogo comercial puede ser correcto para la familia y no para la unidad licenciada. Una lectura en vivo puede ser correcta a las diez y quedar anticuada a las diez y cinco. Cuando la capacidad cambia durante la ejecución, el RFC recomienda notificaciones de cambio, pero el consumidor todavía debe recibirlas y relacionarlas con la decisión que tomó.

Por eso el registro no debería guardar solo true. Debe conservar origen, ubicación, método de consulta, revisión del módulo, modelo y versión del equipo, hora de observación y regla de caducidad. La procedencia es parte del significado operativo de «admitido».

Descubrir no es componer

La lista transport-capability se identifica por el protocolo de transporte. Cada entrada contiene listas separadas para seguridad y codificación. Esta forma describe un repertorio; no documenta una selección.

Tampoco autoriza una acusación fácil. Del hecho de que haya dos listas no se desprende que el borrador garantice falsamente todas sus combinaciones cartesianas. La afirmación responsable es más limitada: pertenecer a los conjuntos no prueba que la terna concreta que pretende usar un controlador funcione ahora. Hay que seleccionar esa terna, probarla y conservar el desenlace.

El RFC 8639 marca el siguiente límite. Una suscripción dinámica no existe en el publicador hasta que este acepta establish-subscription. Enviar la solicitud no basta. El publicador puede rechazarla por diversas razones y devolver información estructurada para orientar un intento posterior.

Aceptar tampoco equivale a entregar de forma sostenida. Es la creación de un estado en el publicador. El destino puede ser inaccesible, el flujo puede suspenderse o terminar y el primer mensaje puede no aparecer. Un cuadro de control honrado separa descubierto, seleccionado, aprobado por política, aceptado y entregando.

La red de gestión solo abre la ventana

El borrador presupone que existe una red de gestión entre el orquestador y el dispositivo, y que la conectividad y el punto de acceso de gestión están aprovisionados. Esa premisa permite consultar el árbol.

No aprovisiona por sí misma el receptor de notificaciones. Tampoco concede a cualquier principal autenticado permiso para crear un flujo hacia cualquier dirección. NETCONF o RESTCONF pueden autenticar al actor; NACM y las reglas locales gobiernan sus acciones; la plataforma receptora y el camino de entrega pueden depender de otras unidades.

En una operación distribuida, el equipo de red lee la capacidad, seguridad aprueba el perfil, telemetría controla el receptor y un proveedor escribe el selector. Si no hay una prueba común, cada uno puede dar por aprobada la parte que pertenece a otro.

El texto dice que los nuevos nodos son de solo lectura y que esos datos no son sensibles. Exige canales seguros y mutuamente autenticados y remite a NACM. No hace falta presentar el catálogo como un secreto. La consecuencia de gobierno nace cuando un hecho legible se usa como mandato. Leer que TLS 1.2 es compatible no significa que esté autorizado para un servicio determinado.

Una prueba de sintaxis no es una prueba de servicio

Datatracker mostraba cero errores y cero advertencias en la validación YANG del 8 de septiembre. La revisión vigente de seguridad figuraba como preparada y la de transporte como casi preparada; IANA aún requería acciones y las revisiones de expertos estaban conformes. Son señales específicas del proceso y conviene citarlas como tales.

La sección de implementaciones declara que Huawei incorporó el documento a un publicador YANG-Push en VRP y Cisco a IOS XR. La propia sección está marcada para que el RFC Editor la retire. Demuestra que hay código declarado, no una matriz pública de interoperabilidad de la revisión 07, una cuota de despliegue, una certificación de producto ni la validez de cada terna.

La identidad dtls12 contiene otra frontera útil: su descripción califica DTLS 1.2 de obsoleto y desaconseja activarlo. No dice que TLS 1.2 esté prohibido; de hecho, el ejemplo lo enumera bajo HTTPS. La política debe distinguir protocolos, contexto y norma, no reaccionar a una coincidencia textual con «1.2».

El recibo que une los estados

Un recibo de decisión de capacidad a suscripción puede vivir en el sistema de operación sin modificar YANG. Primero identifica dispositivo, familia, versión de software y revisión del módulo. Después declara si la observación vino de datos de implementación o de una lectura activa, dónde se obtuvo, cuándo y hasta qué momento se considera fresca.

El recibo conserva la entrada anunciada y la terna realmente elegida: transporte, codificación y seguridad. Añade el principal actuante, el receptor, el punto final, la versión de la política y los parámetros solicitados. El resultado distingue aceptación, rechazo, tiempo agotado, terminación posterior y aceptación sin primera entrega.

Las pistas de error, el reintento, la alternativa elegida y la persona o regla que autorizó una degradación deben quedar unidos. De otro modo, un motor puede mejorar su tasa de éxito recurriendo a una opción menos exigente y presentar el efecto como simple compatibilidad.

The Policy Mirror obliga a localizar dónde reside la decisión: el árbol declara posibilidad, la política concede permiso, el publicador crea el estado y el receptor prueba utilidad. Running-Code Primacy pide que esas huellas coincidan. Reality, Not Advocacy impide exagerar: el borrador no promete una suscripción exitosa. Entrega un catálogo mejor. La operación debe documentar lo que escoge de él.

Fuentes