Resumen

  • El borrador individual del 28 de octubre propone seis tipos de paquete y permite al router suscribirse a avisos por evento, entregas periódicas o ambas cosas.
  • Push Notify anuncia un cambio con un número de serie, sin transportar los objetos modificados. Periodic Update sí describe una entrega de datos a intervalos acordados.

Imaginemos una autorización de origen que acaba de cambiar. La pregunta del operador no es cuándo suena una alarma, sino cuándo el router incorpora la nueva información validada. El borrador de extensión RTR presenta el modo «push» como respuesta a incidentes que exigen rapidez. Sus propios formatos separan el aviso urgente del envío de datos.

La RFC 8210 ya permite que la caché envíe Serial Notify sin que el router lo pida. Al recibirlo, el router puede lanzar de inmediato Serial Query o Reset Query, sin esperar al temporizador de renovación. El borrador vigente de 8210bis mantiene esa opción. La caché toca el timbre; el router decide si pregunta; la respuesta devuelve anuncios y retiradas. La existencia de una consulta posterior no convierte el primer paso en una espera pasiva.

La novedad propuesta es un contrato de suscripción tras la sincronización inicial. El router solicita avisos por evento, actualizaciones periódicas o ambos, y puede cancelar el contrato. El texto pide seis nuevos tipos de paquete a IANA. Son más estados y decisiones por cliente para la caché; ese coste necesita una mejora demostrable en el recorrido completo.

El paquete de evento Push Notify lleva identificador de suscripción, tipo de aviso y número de serie. Puede indicar cambios en ROA, ASPA o claves de router, pero el diagrama no incluye esos objetos. El borrador tampoco traza la conversación que entregaría los datos después del aviso. Así, la palabra «urgente» se aplica al timbre, mientras la llegada de la nueva información queda sin especificar.

En Periodic Update aparece la mercancía: Cache Response, cero o más paquetes de datos y End of Data a un intervalo negociado. La caché indica el número de serie que cree que posee el router. Si no coincide con el número real, el router debe rechazar los datos. Esa comprobación protege el estado local; también obliga a medir cuánto tarda una entrega que supera la comprobación, no solo cuánto tarda en salir del servidor.

El registro oficial del documento lo muestra como propuesta individual de Standards Track en estado I-D Exists. No ofrece prueba de despliegue ni comparación reproducible de latencia. La pieza que falta es concreta: secuencia de transferencia tras un evento y medición hasta la aceptación del mismo cambio por el router.