Resumen

  • Si el startTime solicitado precede al historial conservado, RFC 5277 inicia la repetición en la notificación más antigua disponible. La finalización puede ser correcta y la cobertura insuficiente.
  • Stream, filtro y control de acceso definen una vista por sesión. El marcador no acredita generación exhaustiva, entrega al cliente, calidad del reloj ni efecto operativo.

Completo respecto de qué

La palabra “completo” sólo es verificable si el conjunto está nombrado. En RFC 5277 ese conjunto no es “todos los sucesos”. Es la parte de replay aplicable a una suscripción concreta.

Supongamos que el cliente pide A–C y el log conserva B–C. El protocolo permite comenzar en B y terminar con replayComplete. El intervalo A–B no queda vacío por prueba; queda sin evidencia.

RFC 8639 actualiza el modelo de suscripciones y RFC 8641 lleva el esquema de gestión a YANG. La lección de RFC 5277 no depende de presentar su diseño de 2008 como única arquitectura vigente: un recibo de proceso conserva su alcance aunque evolucione el mecanismo.

La fecha de creación no es la fecha del evento más antiguo

Replay requiere logging y es opcional. El tamaño, la política y la retención son específicos de la implementación. replayLogCreationTime puede ser anterior a la notificación más antigua todavía disponible; replayLogAgedTime ayuda a describir el envejecimiento.

El contenedor puede existir desde hace meses mientras su contenido sólo cubre horas. Usar la edad del log como prueba de profundidad histórica confunde identidad del recurso con datos retenidos.

El recibo debe guardar comienzo solicitado, comienzo efectivo, horizonte de aging y generación o reset del log. Cuando el comienzo efectivo avanza, la plataforma debe presentar un hueco, no una reproducción exitosa sin calificadores.

El stream es una selección

Un stream agrupa notificaciones conforme a criterios de forwarding. El stream predeterminado NETCONF contiene todas las notificaciones XML NETCONF que el servidor soporta. Eso no obliga a que cada cambio interno produzca una notificación.

La configuración de streams y las fuentes adicionales quedan fuera del documento. Para afirmar “no ocurrió”, hace falta demostrar por separado que el stream cubría de forma completa la clase de hechos investigada.

También hace falta una versión de la definición. Una misma etiqueta de stream puede representar otra selección después de una actualización.

Filtro y permiso cambian la historia visible

El filtro de create-subscription decide qué elementos coinciden. Después, el control de acceso puede descartar una notificación para una sesión sin permiso. Por eso dos clientes pueden obtener secuencias diferentes y ambos recibir un marcador válido.

replayComplete significa “terminé tu vista”, no “te revelé todo lo que el sistema sabe”. Un análisis serio conserva filtro, identidad de sesión, versión de policy y contadores antes y después de cada reducción.

Si los derechos cambian entre dos ejecuciones, sus resultados no son comparables sin esa provenance. La diferencia puede provenir de visibilidad, no de la realidad subyacente.

Aceptar la suscripción no acusa cada notificación

La respuesta RPC positiva confirma que la operación de suscripción fue aceptada. Las notificaciones posteriores son mensajes unidireccionales sin respuesta individual.

Un servidor puede emitir correctamente todos los elementos mientras transporte, cola, decoder o almacenamiento del cliente pierde algunos. Para una afirmación extremo a extremo se necesita un checkpoint receptor o un inventario independiente.

notificationComplete no repara esa brecha. Señala el fin de la suscripción cuando existe stop time. replayComplete señala el fin de la porción histórica. Son dos límites de protocolo, no dos certificados de verdad.

El enlace con tráfico vivo puede tener costura

Sin stop time, después del replay se envían notificaciones generadas desde la creación de la suscripción y luego las nuevas. La transición está ordenada conceptualmente, pero el marcador no prueba ausencia de duplicados, pérdidas o reordenamiento en consumidores posteriores.

eventTime corresponde al momento de generación según la fuente. No certifica sincronización ni equivale al tiempo de llegada o persistencia. Ordenar por ese campo puede producir una narración limpia con causalidad incierta.

El recibo debe enlazar identidad del servidor, capability, stream y versión, tiempos pedidos, ventana efectiva, log generation, filtro, policy, RPC, marcadores, transición al vivo, tiempos de fuente/envío/recepción, persistencia y contraste con el estado autorizado.

Fuentes