Resumen

  • El borrador de API v3 de PeeringDB propone un servicio público de solo lectura, pensado para varios sitios, con metas de disponibilidad y frescura de los datos.
  • Es una propuesta abierta a comentarios, no un lanzamiento: faltan las reglas de acceso y el contrato API detallado, y no hay mediciones de rendimiento en producción.

El borrador pone un reloj a una API futura, pero no le asigna una fecha de lanzamiento. El documento de PeeringDB, fechado el 18 de septiembre, fija una meta de disponibilidad de al menos 99,95 %, plantea que el 99 % de los cambios se vea en un minuto y establece un techo de 15 minutos para las respuestas con los datos más recientes, incluidas las que pasan por caché. No indica cuándo se implementará el servicio. Su estado lo define como una primera versión para comentarios y revisión.

La actualización de PeeringDB que APNIC publicó el 7 de octubre explica el motivo del proyecto. Leo Vegoda, responsable de producto, señala dos objetivos: separar lectura y escritura para servir datos desde varios lugares, y hacer más eficientes las consultas habituales entre objetos relacionados. También pide a los usuarios de la API que opinen antes de la implementación. El contrato detallado está en la página de PeeringDB; APNIC es el canal editorial, no quien opera la API.

El alcance propuesto es acotado. La versión 3 sería pública y de solo lectura, en paralelo con la versión 2; las escrituras seguirían en v2. La primera búsqueda se limitaría a nombres y números de sistema autónomo. Quedan fuera de la primera entrega las vistas privadas o específicas por clave, la expansión anidada, la búsqueda de texto completo ordenada por relevancia y las consultas espaciales o de distancia. Los objetos planos, la sincronización incremental y las instantáneas diarias permitirían a los usuarios crear y actualizar sus propias copias.

Las respuestas identificarían la versión del conjunto de datos y un punto de consulta informaría qué tan recientes son los datos de origen.

Las metas de frescura tienen límites definidos. Se medirían desde un cambio en la fuente hasta una respuesta con los datos más recientes, incluido el retraso de caché. La medición excluiría las instantáneas diarias, los recorridos históricos, los espejos de terceros y el intervalo de consulta del cliente. El techo de 15 minutos sirve para generar una alerta, no para detener el servicio: el borrador dice que un incumplimiento no debe impedir que se sigan atendiendo consultas.

Esto importa a los operadores que consultan PeeringDB para revisar redes, instalaciones y relaciones con puntos de intercambio. La propuesta establece una meta para que su vista pública se ponga al día; no demuestra que los datos sean completos ni que los registros aportados por participantes sean correctos. PeeringDB tampoco es un plano de control de enrutamiento: el proyecto no cambia asignaciones de los RIR ni decisiones de BGP.

Antes de implementar, quedan piezas importantes por resolver. OpenAPI debe definir la sintaxis de las consultas, las respuestas, los errores y la compatibilidad. También falta decidir la política de acceso y límites de consultas. El documento no especifica el período de medición de la disponibilidad ni una fecha de lanzamiento. Un porcentaje en un diseño no equivale a un registro de disponibilidad.

La siguiente evidencia útil será una especificación revisada, las reglas de acceso ya definidas y, más adelante, mediciones en producción que separen la frescura de origen del comportamiento de cachés y clientes. Hasta entonces, API v3 es un contrato propuesto para una futura vía de lectura, no un servicio disponible para que los operadores dependan de él.

Fuentes