Resumen

  • Andy Clyde dijo en RIPE 93 que el equipo de Internet Society/Pulse consulta PeeringDB para analizar IX y necesita registros desde 2019 para volver a procesarlos.
  • El borrador de API v3 cuantifica la frescura de los datos recientes, excluye las consultas históricas de esa medida y pide publicar una ventana de retención sin fijar aún su duración.

El problema de Clyde no cabe en un gráfico de latencia. En el panel de PeeringDB de RIPE 93, habló desde el lado de quien estudia la evolución de los puntos de intercambio, no de quien programa un router con el dato de hoy. Para su equipo, cambiar al borrador de API podría llevar un par de semanas. Volver a los registros de 2019 y recalcular una serie requiere que esos registros sigan disponibles.

La transcripción oficial recoge otras peticiones para el rastreador de IX: datos de tráfico, clasificaciones de redes y tipos de conjuntos de datos. Clyde aceptó que algunas puedan quedar fuera de PeeringDB. También señaló que mantener dos API tiene un coste tanto para clientes como para el propio servicio. Cambiar la sintaxis de una consulta es trabajo de desarrollo; perder años de observaciones cambia la pregunta que puede responderse.

El borrador v3 de PeeringDB, fechado el 18 de septiembre, propone lectura pública junto a v2, sincronización incremental e instantáneas diarias. Su objetivo es que el 99 % de los cambios recientes aparezca en un minuto. Las recorridas históricas quedan expresamente fuera de ese reloj. El documento obliga a publicar cuánto tiempo se servirán los datos antiguos, pero aún no da la cifra. Las URL de los volcados actuales no se modifican en esta propuesta.

La condición que Clyde puso sobre la mesa es verificable: hasta qué fecha podrá volver un investigador y repetir un análisis con datos públicos documentados.