Resumen

  • El borrador hace portables el tiempo de generación, hostname, un contador de 32 bits por proceso editor y la semántica del tiempo de observación; cada dato sigue siendo una afirmación limitada por esquema y contexto.
  • Para actuar sobre una notificación hacen falta recibos distintos de esquema, identidad autenticada, época del proceso, reloj, suscripción, contenido, trayecto posterior y resultado autoritativo.

El colector ve un objeto ordenado: raíz envelope, fecha válida, hostname conocido, número consecutivo y una actualización YANG-Push que se decodifica dentro de contents. No hay fallo visible. El error sería ampliar esa constatación hasta afirmar que la observación es completa y verdadera.

La revisión 05, fechada el 18 de mayo de 2026, responde a una carencia concreta. El encabezado de RFC 5277 solo posee eventTime obligatorio y no admite extensiones. Cuando un receptor envía la notificación a un broker o una base temporal, puede perderse el contexto del transporte de origen. El borrador reúne metadatos y carga útil en una estructura YANG que se codifica como XML, JSON o CBOR.

El Datatracker lo presenta como Internet-Draft activo del grupo NETCONF, con intención de Proposed Standard y pendiente de avance por la presidencia. No es un RFC. Su aportación es hacer explícitas ciertas afirmaciones; no darles más alcance del que soportan.

El esquema acredita forma, no realidad

Al activarse, envelope contiene event-time obligatorio, hostname y sequence-number opcionales, y un contents de tipo anydata. RFC 8791 define la estructura abstracta; RFC 7951 y RFC 9254 especifican JSON y CBOR.

Una validación correcta puede demostrar nodos, tipos, namespaces y codificación respecto del conjunto de esquemas cargado. No demuestra que ese conjunto sea el previsto, que se validara el interior de contents ni que los valores correspondan al mundo. El 10 de septiembre de 2026 la página de Datatracker mostraba cuatro errores y dos avisos YANG. El historial también conserva una declaración anterior de ejecuciones limpias de yanglint y pyang, con la salvedad de que los ejemplos no validaron el anydata. Son fechas y alcances distintos; ninguno es prueba de una implementación en producción.

El recibo debe enumerar versión del módulo, features, serialización, namespaces o SID, versión del validador, esquemas cargados y profundidad de la revisión.

El hostname no se autentica a sí mismo

El texto define hostname como el nodo que publicó el mensaje y dice que lo identifica de forma única en la red. La descripción YANG añade que suele configurarlo un administrador. Es una etiqueta útil bajo una autoridad de nombres, no una credencial.

La sección de seguridad exige transporte protegido y autenticación mutua para NETCONF o RESTCONF. También advierte que el hostname puede facilitar el mapa de la red o la inyección de notificaciones falsas. Ver edge-17.example en un canal no autenticado solo prueba que alguien incluyó esa cadena.

La identidad exige ligar el valor al peer autenticado o clave firmante, certificado y época de clave, dispositivo, proceso editor, autoridad de nombres y autorización de la suscripción. RFC 8341 recuerda además que los permisos pueden filtrar o eliminar contenido. Autenticación y autoridad para publicar no son sinónimos.

Una secuencia limpia vive dentro de una época

sequence-number es counter32: empieza en 1, avanza por cada notificación del proceso editor y, después de 4294967295, vuelve a 0. Dentro de una época estable y observada, un hueco o inversión revela discontinuidad.

El borrador no asigna un identificador duradero a esa época ni prescribe persistencia tras reiniciar. Si el receptor empieza en 914, no ve lo omitido antes. Un proceso nuevo puede usar el mismo hostname; un relay puede perder, duplicar o reordenar; el contador puede hacer wrap. “Sin huecos” significa únicamente que no se observaron huecos en el tramo conservado, para una identidad y época declaradas.

El recibo de continuidad debe unir contador, proceso autenticado, arranque, primera muestra, interpretación del cero, inicio de observación, ruta de relays y confirmación de persistencia.

Cada reloj contesta algo diferente

event-time marca la generación del evento, que el borrador explica como el instante de construir y enviar el mensaje. La extensión de observación agrega timestamp para la medida periódica o el cambio observado, y point-in-time distingue current-accounting, initial-state y state-changed.

Así se evita indexar en el intervalo equivocado una medida tomada antes de un límite pero enviada después. Sin embargo, el formato no certifica el reloj. RFC 6991 define date-and-time y permite -00:00 cuando la zona es desconocida. Una marca con fracciones no acredita sincronización NTP/PTP, trazabilidad UTC, error acotado o monotonía.

Tiempo de observación, generación, anchor-time, llegada y escritura deben conservarse por separado junto con fuente y margen de incertidumbre.

Declarar capacidad no acredita una instancia

RFC 9196 permite publicar capacidades de implementación o de ejecución. La revisión 05 añade soporte del envelope, hostname/secuencia y tiempo de observación. Eso facilita la negociación.

Un booleano verdadero solo declara soporte. No acredita que el interruptor global esté activo, que un campo opcional aparezca en este mensaje, que sea correcto o que cada intermediario lo conserve. Soporte, configuración, emisión y custodia son estados diferentes.

Cambiar el interruptor global termina todas las suscripciones existentes y obliga a enviar subscription-terminated con el encabezado anterior. Pueden coexistir formatos distintos en una red. El recibo de migración debe registrar transacción, suscripciones terminadas, compatibilidad de receptores y nuevas épocas; el árbol de capacidades no prueba por sí solo que no hubo intervalo ciego.

contents depende del contrato de suscripción

RFC 8639 vincula entrega con filtros, receptores, permisos y ciclo de vida. RFC 8641 distingue periodicidad y on-change, datastore, filtro, anchor, dampening y sincronización. Una push-update es completa bajo los términos de su suscripción; una push-change-update puede condensar cambios intermedios durante dampening.

El envelope no repite ese contrato. Un subscription ID permite buscarlo, pero no demuestra que la versión hallada gobernara la generación. Puede cambiar filtro, datastore, autorización, disparador o receptor mientras hostname y secuencia siguen normales. Conviene sellar la configuración efectiva y guardar cada evento de ciclo de vida.

RFC 8342 separa estado intended, running y operational. Una serialización fiel a una vista no demuestra comportamiento de forwarding, impacto de servicio ni resultado comercial.

La custodia posterior necesita identidad de contenido

El borrador base dice que contents lleva sin cambios los valores de la notificación, pero no incluye firma. Un canal NETCONF o RESTCONF seguro protege una asociación. Al decodificar, recodificar, reenviar, agregar o guardar, esa garantía no acompaña automáticamente la carga.

El borrador de procedencia YANG propone una extensión COSE firmada exactamente sobre contents. También limita su alcance: protege origen e integridad al firmar, pero no frescura, corrección de datos de un firmante legítimo, ausencia de compromiso de clave, firma de cada intermediario ni la asociación fiable entre Key ID y fuente autoritativa.

El recibo conserva digest, canonicalización, serialización, firmante, política de clave, resultado, material de frescura y transformaciones. Después aún hay que comprobar si la observación firmada era correcta.

Ocho recibos sin autoridad prestada

La conclusión requiere ocho recibos: esquema y alcance de validación; identidad autenticada; continuidad del proceso; reloj e incertidumbre; suscripción y autorización; identidad y firma del contenido; transporte y custodia posterior; datastore autoritativo y resultado independiente.

El envelope ayuda a transportarlos. No debe permitir que hostname tome prestada la autenticación, el contador un historial durable, el timestamp un reloj sincronizado, capability la presencia real o unos bytes válidos la verdad operativa.

Registro normativo complementario

El historial de Datatracker fija el límite de versión. La sintaxis temporal procede de RFC 3339; el encabezado anterior, de RFC 5277; la gestión segura incluye RFC 6241 y RFC bied8040; YANG se define en RFC 7950; y el marco de planos de telemetría, en RFC weird9232. Son referencias mecánicas y de contexto, no resultados desplegados.