Resumen

  • Los identificadores de publicador y mensaje, los números de segmento, el indicador final y la ventana de aceptación permiten afirmar qué armó un receptor, pero no qué desapareció antes de que comenzara su secuencia visible.
  • La integridad exige recibos separados de asociación, reensamblaje, continuidad, identidad, contexto de suscripción, tiempo, seguridad de carga y correspondencia con el estado operativo autorizado.

El receptor ve 0, después 2 y finalmente 1. Como el segmento 2 lleva el indicador L, sabe que el conjunto esperado termina allí; ordena, concatena y entrega una notificación. Ese resultado es valioso y estrecho. No demuestra que la telemetría sea completa.

La revisión 26, fechada el 29 de julio de 2026, define una asociación UDP unidireccional para suscripciones configuradas en redes controladas. Cada datagrama sin fragmentación IP contiene un mensaje o un segmento y no se espera retransmisión. Datatracker la registra como Internet-Draft activo del grupo NETCONF, destinado a Proposed Standard; su historial muestra la evolución. Todavía no es un RFC.

Lo que sí demuestra el reensamblaje

Los segmentos comparten Message Publisher ID y Message ID. Segment Number comienza en cero y no vuelve a empezar; L marca el último y declara el total esperado. El receptor admite desorden, elimina duplicados, espera el conjunto y concatena por número. Las demás opciones solo están garantizadas en el primer segmento.

Así se obtiene una secuencia concreta de bytes bajo unos campos concretos. No se demuestra que duplicados con igual número tuvieran los mismos bytes, que el primer segmento no fuera sustituido ni que las claves pertenecieran a un único periodo auténtico del proceso. El recibo debe conservar huellas de segmentos aceptados y descartados, el conjunto 0..L, opciones iniciales, huella reconstruida, tiempo de espera y presupuesto de memoria.

El borrador exige soportar al menos 96 KB y 64 segmentos en el receptor, recomienda menos de 64, unos diez segundos de reensamblaje y nunca más de veinte. Perder una pieza inutiliza todo el mensaje. RFC 8900 explica la fragilidad de la fragmentación IP; segmentar en la aplicación la evita, pero mantiene la amplificación de pérdidas.

La continuidad depende del punto de observación

Message ID arranca en un valor aleatorio de 32 bits, aumenta de uno en uno y vuelve a cero tras el máximo. Un salto puede señalar pérdida dentro de una época estable. Un mensaje perdido antes del primer ID observado no deja salto alguno. Además, el receptor puede no estar activo al comenzar la suscripción. Reinicios, reutilización del Publisher ID, relés, caídas del receptor, vuelta del contador y movimiento de la ventana redefinen “continuo”.

El receptor puede comparar sus entregas con sent-event-records de RFC 8639. La diferencia apoya una inferencia de pérdida solo si coinciden suscripción y época. Duplicados de un mensaje completo y elementos fuera de ventana no son fallos de entrega según el borrador; necesitan contadores diagnósticos propios.

Identidad no es correlación

Message Publisher ID distingue localmente un proceso. Si la unicidad no cruza el dominio de colecta, se añade la IP de origen; los relés deben preservar la distinción. Eso correlaciona, pero no autentica. Cuando las capas inferiores no protegen la red, el borrador exige transporte seguro y perfila DTLS. RFC 9147 protege una asociación DTLS 1.3 contra alteración y repetición y autentica a sus pares.

Aun así, un par auténtico puede carecer de autoridad para esa suscripción o cambiar de proceso tras un reinicio. RFC 8341 mantiene separada la autorización de gestión. Hay que ligar dispositivo, proceso, credencial y época, dominio de unicidad, tupla de red, relé, decisión de ventana y autoridad de suscripción.

El encabezado no guarda toda la intención

El tipo de medio distingue JSON, XML, CBOR o codificación privada. La suscripción conserva objetivo, filtro, disparador, periodo, amortiguación, receptor y versión. RFC 8641 hace de esos parámetros la semántica de YANG-Push. Una secuencia de Message ID puede seguir limpia mientras una modificación cambia el significado de cada dato.

Tampoco hay un único tiempo: evento, envío, llegada y final de reensamblaje. Ordenar por Message ID no prueba exactitud de reloj ni causalidad del sistema. El recibo temporal necesita fuente de reloj, incertidumbre, las distintas marcas y la versión de suscripción.

Un checksum UDP válido y DTLS protegen bytes, no unidades, frescura ni verdad YANG. RFC 8342 separa running, intended y operational. El publicador puede transmitir fielmente una vista que no es la autoridad decisiva. Por eso la última verificación debe observar, por otra vía, el dispositivo, ruta, cola, interfaz o servicio relevante.

Un camino sobrecargado también rompe la integridad

RFC 8085 limita el uso masivo de UDP. La revisión 26 exige capacidad reservada y QoS, recomienda CS2, regulación de ráfagas y tasas acotadas. Una secuencia intacta que agota memoria del receptor o perjudica tráfico de gestión no es un éxito operativo.

La cadena completa reúne ocho recibos: asociación; conjunto de segmentos; continuidad; fuente autenticada; suscripción y codificación; tiempo; checksum, DTLS, tasa y QoS; estado autorizado y resultado independiente.

Fuentes y límite de revisión

El contexto incluye RFC 8639, RFC 8641, RFC 8342, RFC 8341, RFC 8085, RFC 8900 y RFC 9147. Las revisiones históricas fueron Ready with nits para TSVART sobre -23, Has issues para OPSDIR sobre -21 y On the right track para YANG Doctors sobre -20. Ninguna juzga de nuevo la revisión 26.