Resumen

  • El primer borrador de API v3, publicado el 18 de septiembre, mantendría las escrituras en v2 y abriría un plano de lectura pública y de solo lectura.
  • Que una respuesta pueda consultarse o almacenarse en caché no otorga por sí mismo permiso para guardar y redistribuir datos en bloque con fines comerciales.

Una consulta pública resuelve el acceso a un dato; no concede automáticamente el derecho a empaquetar ese dato y venderlo. Esa diferencia es el punto más práctico del borrador de API v3 de PeeringDB.

El documento del 18 de septiembre se presenta como una primera ronda de comentarios. Propone una API pública, de solo lectura y diseñada para servirse desde varias ubicaciones, junto a la API actual, llamada v2. Las actualizaciones seguirían en v2 al comienzo. Para la nueva interfaz, PeeringDB plantea objetos planos, sincronización incremental y copias diarias como vía de carga masiva y respaldo. La explicación publicada tres días después vincula la separación entre lectura y escritura con dos objetivos concretos: bajar la latencia y mejorar la resiliencia.

El borrador ya fija métricas de servicio: 99,95% de disponibilidad, el 99% de los cambios visible en un minuto y un límite de frescura de quince minutos para las respuestas más recientes. Ese límite es una señal para alertar; no debe impedir que el servicio continúe entregando datos. Las copias diarias, los recorridos históricos, los espejos de terceros y el intervalo de consulta del cliente quedan fuera de la métrica. Además, todos los usuarios recibirían el mismo conjunto público; una clave API no alteraría la visibilidad.

La política de uso aceptable vigente regula algo distinto. Salvo para fines de operación de Internet aprobados por PeeringDB, prohíbe reproducir, guardar en un sistema de recuperación o transmitir sus datos sin permiso previo. Incluye entre esos fines la solución de problemas de red, la notificación de abusos y la investigación y el análisis de Internet. La entrega masiva a otra organización requiere aprobación, mientras que las listas de marketing, los mapas demográficos y otras aplicaciones comerciales quedan excluidas. Cada solicitud se evalúa según el propósito declarado.

El borrador no anuncia una modificación de esa política. Que la API permita cachear respuestas y que su sincronización incremental contemple un cliente que sondea cada cinco minutos para mantener una copia local no equivale a una licencia general. Tampoco la exclusión de espejos de terceros de la medición de frescura o del alcance de retirada constituye permiso para redistribuirlos. Son límites operativos descritos por el borrador; las condiciones de uso siguen en otro documento.

La retirada de datos muestra por qué importa esa separación. La proyección pública conservaría contactos, notas y coordenadas precisas que ya están marcados como públicos. PeeringDB tendría que publicar un periodo de conservación y ofrecer una retirada urgente de lo que sirve. Las copias que terceros ya poseen quedan fuera de esa política. El borrador exige que los deltas muestren eliminaciones y retiradas, pero la especificación OpenAPI aún debe definir las solicitudes y respuestas exactas.

También siguen abiertas las condiciones de acceso, los límites de velocidad, la ruta concreta de v3 y varias decisiones sobre campos y tipos de objetos. PeeringDB pide a su comunidad comentarios sobre el diseño y el cambio eventual desde v2; todavía no ha anunciado una fecha de lanzamiento. Para las empresas, la cuestión no es solo cuánto tarda una lectura, sino qué uso está autorizado después de ella.

Fuentes