Resumen

  • ARIN afirmó en junio de 2024 que la aceptación de un estándar común activaría la implementación de geofeed en RDAP, ARIN Online y Reg-RWS; la sugerencia permanecería Open hasta que la función estuviera desarrollada y desplegada.
  • RFC 9877 se publicó como Standards Track en octubre de 2025. Define geofeed1, rel=geofeed y application/geofeed+csv, con registro formal para que clientes y servidores compartan semántica.
  • El 12 de septiembre de 2026, la lista ACSP aún mostraba 2024.10 como Open. La respuesta help de RDAP en vivo no incluía geofeed1; un objeto de red elegido como ejemplo llevaba la URL únicamente en Registration Comments.
  • Nada de eso demuestra inactividad ni ausencia en toda la base. Sí demuestra la necesidad de un recibo fechado que conecte el disparador normativo con cada producto, la migración, la distribución masiva, la privacidad, las pruebas y el cierre de la sugerencia.

La promesa cambió de pregunta

Una dependencia técnica puede ser una forma de prudencia. Si cinco RIR publican la misma idea con cinco esquemas diferentes, el coste no desaparece: se traslada a cada cliente RDAP y dura años. Esperar a que la IETF estabilice nombres y comportamiento evita ese pasivo.

La dependencia, sin embargo, tiene un antes y un después. Antes del estándar, la pregunta es qué acuerdo falta. Después, la pregunta es qué superficie lo implementa, con qué datos y cómo puede comprobarlo un usuario.

La Sugerencia ACSP 2024.10 llegó el 3 de junio de 2024. Pedía un atributo geofeed opcional en los objetos de red. Su punto de partida era concreto: en ARIN, un titular podía escribir Geofeed [URL] en un comentario. La intención podía resultar obvia para una persona, pero una aplicación debía buscar texto libre, separar el URL de sus alrededores y decidir si aquella frase realmente era canónica.

ARIN respondió el 7 de junio. Explicó que los cinco RIR trabajaban en la IETF sobre una extensión geofeed para RDAP. Cuando el estándar fuera aceptado, ARIN implementaría el cambio en RDAP y añadiría las funciones necesarias a ARIN Online y Reg-RWS. También mencionó un formato común de descarga masiva. La sugerencia quedaría abierta hasta el desarrollo y despliegue de la función.

No había plazo ni definición de “aceptado”. Puede haber significado publicación como RFC, aprobación previa, adopción de un perfil entre RIR o algún criterio posterior. Por eso no hay base para declarar incumplimiento. Pero sí hay base para pedir que el registro público cambie de lenguaje una vez que el hito externo ha ocurrido.

Tres elementos que una aplicación puede leer sin adivinar

RFC 9877 apareció en octubre de 2025 como Standards Track. No obliga a cada servidor RDAP a ofrecer geofeeds. Establece cómo debe hablar un servidor que decida hacerlo.

La relación geofeed define la función del enlace. El tipo application/geofeed+csv define la representación del archivo. El identificador geofeed1 permite declarar que el servidor aloja URL geofeed para sus objetos de red IP. IANA incluye el identificador en su registro de extensiones RDAP.

Un servidor que use geofeed1 debe colocarlo en rdapConformance tanto en help como en respuestas de búsqueda o consulta que contengan objetos de red IP. Si dispone del URL para un objeto y puede devolverlo, ha de incluir el enlace correspondiente. La declaración convierte una lista de enlaces en una promesa sobre el comportamiento del servicio.

El RFC también conserva una ruta menos fuerte. Un servidor puede usar la relación y el tipo de medio registrados sin declarar geofeed1. RDAP no exige una extensión para cada relación ya registrada. La diferencia es útil: un enlace tipado habla de ese objeto; el identificador habla de una capacidad del servidor.

Por eso una prueba de help tiene un valor preciso. Puede verificar si se hace la declaración. No puede registrar por sí sola todos los enlaces existentes ni leer las intenciones de ingeniería.

Lo que dicen dos respuestas y todo lo que callan

La respuesta help de ARIN capturada el 12 de septiembre de 2026 enumera el nivel básico de RDAP, el perfil NRO, CIDR, datos de origin-AS, búsqueda RIR y otras extensiones. geofeed1 no está entre ellas.

La frase correcta es: la respuesta observada no declaró la extensión en ese momento. Decir que ARIN “no tiene geofeed” sería saltar de un dato público a una conclusión sobre código, pilotos y planificación que el dato no contiene.

La respuesta seleccionada para 154.54.100.0/22 ofrece otro ángulo. Su bloque Registration Comments incluye Geofeed ai.net/geofeed.csv. El conjunto de conformidad tampoco contiene geofeed1; los enlaces usan self, alternate y up, no rel=geofeed.

El ejemplo se buscó precisamente porque conserva la convención descrita en la sugerencia. No es una muestra aleatoria. No permite calcular cuántos objetos usan comentarios, negar que haya enlaces tipados en otros objetos ni validar el archivo señalado. Un URL publicado es una vía de descubrimiento, no una medición de ubicación física ni una prueba de enrutamiento.

El ejemplo cumple otra función: obliga a preguntar cómo se convertirá la historia. Una implementación nueva no comienza en una base vacía.

Una frase de ARIN 57 dejó abierta la cronología

En abril de 2026, durante ARIN 57, el informe de ingeniería habló de mejoras RDAP para geofeed y servicios de directorio RPKI. Añadió que aquello estaba pasando entonces por la IETF. RFC 9877 llevaba unos seis meses publicado.

La frase puede tener explicaciones benignas. Quizá se refería a un documento relacionado, a un perfil NRO, a coordinación de implementación o a material que no se actualizó. La transcripción no demuestra parálisis ni permite conocer un backlog privado.

Lo que sí prueba es una falta de reconciliación pública. Si el RFC ya no es la dependencia, conviene nombrar la dependencia real. Una corrección breve protege al propio ARIN: evita que cada lector invente una causa distinta para el estado Open.

La migración decide qué texto gana autoridad

El flujo atraviesa varias superficies. ARIN Online permite que una persona gestione el dato. Reg-RWS permite automatizar. RDAP publica. Una salida masiva distribuye a consumidores de gran volumen. Cada superficie puede cambiar en fecha distinta y con reglas diferentes.

Un campo disponible en ARIN Online pero ausente en Reg-RWS obliga a mantener procedimientos paralelos. Un enlace presente en una consulta sin geofeed1 en help ofrece una semántica a nivel de objeto, pero no la promesa general de la extensión. Una instantánea masiva que se actualiza después puede mostrar durante horas o días otro estado. “Desplegado” debe ser una matriz, no una casilla.

Los comentarios existentes son el punto de riesgo. Algunos contienen un URL limpio. Otros pueden contener más de uno, texto condicional, direcciones caducadas o menciones que no pretendían ser campos. Una extracción automática elevaría texto antiguo a una afirmación estructurada sin pedir confirmación al titular.

Mantenerlo todo intacto también tiene coste. Dos mecanismos de descubrimiento pueden competir. Un consumidor seguirá leyendo el comentario, otro preferirá el enlace, y ambos cachearán resultados distintos.

La migración necesita un inventario con categorías: candidato claro, ambiguo, múltiple, inaccesible y no pertinente. Los casos que cambien autoridad requieren confirmación del titular. Debe conservarse el texto original, definirse la precedencia cuando conviven comentario y campo, y existir una reversión. Los objetos más específicos necesitan pruebas propias para impedir que una referencia amplia tape una declaración estrecha.

La firma autentica al emisor, no la ciudad

RFC 9632 describe cómo descubrir geofeeds mediante RPSL y ofrece autenticación RPKI opcional. La autenticación puede ayudar a demostrar que el archivo procede de una parte autorizada para los recursos cubiertos. No viaja a la ciudad declarada ni observa dónde se entrega el tráfico.

Conviene separar cuatro afirmaciones. El titular proporciona el URL. ARIN publica el puntero. Una firma opcional refuerza la procedencia. El consumidor decide si usa la ubicación declarada. Ni el enlace ni la firma convierten una afirmación del editor en verdad geográfica.

La estructura tipada facilita la recogida a gran escala. Precisamente por eso importan la privacidad, el borrado y la antigüedad de las copias. RFC 9632 desaconseja usar RDAP ordinario para la recuperación masiva. ARIN ya había mencionado un formato común de descarga en 2024: reconocía que una API transaccional y una distribución completa son productos distintos.

El recibo debe decir cuándo entra un cambio en la salida masiva, cuánto tiempo se conserva, cómo se verifica la integridad y qué ocurre con una retirada. También debe indicar cómo se interpreta una omisión por restricción regulatoria o similar.

El recibo que permitiría cerrar la cadena

Primero, el disparador. ARIN debería nombrar RFC 9877, los errata relevantes y cualquier perfil NRO o acuerdo entre RIR que considere necesario. Debe fechar cuándo consideró satisfecha la condición de 2024. Si persiste otra condición, necesita nombre y alcance.

Segundo, la matriz de interfaces. ARIN Online, Reg-RWS, RDAP help, consulta de objetos y salida masiva necesitan estados definidos: diseño, pruebas, disponible, predeterminado, deprecado o completo. La matriz ha de mostrar el token, la relación y el tipo de medio esperados, junto con un caso positivo y otro negativo comprobables.

Tercero, las reglas de edición. Qué roles pueden añadir o quitar el URL, si HTTPS es obligatorio, qué normalización se realiza, si existe una vista previa y qué pasa cuando el sitio de destino no responde. Una interrupción temporal no debería borrar silenciosamente una decisión del titular.

Cuarto, el libro de migración. Cantidad de comentarios candidatos, clases de resolución, necesidad de confirmación, precedencia y reversión. Las estadísticas pueden ser públicas sin revelar los URL.

Quinto, los tiempos. Aceptación del cambio, lectura en ARIN Online, lectura en Reg-RWS, visibilidad RDAP e inclusión en el lote deben ser momentos separados. Una ventana de consistencia explícita es preferible a una fecha única que oculta retrasos normales.

Sexto, pruebas y gobierno. Casos válido, ausente, malformado, más específico, multilingüe, retenido y eliminado; fechas de despliegue y vuelta atrás; explicación de la frase de ARIN 57; y disposición final de ACSP 2024.10 enlazada a esas pruebas.

Un límite común para ARIN y para sus críticos

El recibo evita dos excesos simétricos. La ausencia de geofeed1 no se convierte en prueba de que nadie trabajó. El progreso interno tampoco se convierte en prueba de que el servicio público está completo.

ARIN obtiene una afirmación defendible: en una fecha, determinadas respuestas soportan determinados elementos con estas reglas. Los usuarios obtienen una prueba repetible. Y todos conservan las distinciones que importan: Open no significa inactividad; un objeto no representa una base; un puntero no es una ubicación; una firma no es observación.

Puede que el resultado sea que otra pieza normativa sigue pendiente. Puede que parte del producto esté ya disponible y falte documentación. La claridad no exige escoger de antemano una conclusión. Exige que la condición, la interfaz y la evidencia compartan el mismo reloj.

Fuentes