Resumen

  • El volcado oficial de AFRINIC modificado el 30 de agosto de 2026 contiene 3.790 objetos RPSL con la forma exacta remarks: Geofeed HTTPS-URL; 3.573 son objetos de direcciones inetnum o inet6num, el ámbito de descubrimiento de RFC 9632.
  • La forma de observaciones no es un incumplimiento. RFC 9632 la define para bases que todavía no ofrecen geofeed: y exige que los consumidores acepten ambas representaciones durante la migración.
  • Los esquemas en vivo de AFRINIC muestran remarks: pero no geofeed:. En el archivo público del DBWG hay una solicitud de work item y evaluación de impacto, más varias reiteraciones, sin que se haya encontrado una disposición pública posterior hasta agosto de 2026.
  • Un recibo acotado puede documentar la decisión, la autorización de escritura, las reglas de sintaxis y conflicto, el inventario heredado, la proyección WHOIS/RDAP, los límites de autenticación y privacidad, las pruebas y la reversión.

La cifra que mejor explica el problema no es 3.790 ni 3.573. Es la diferencia de 217.

Una búsqueda literal en la base pública de AFRINIC encuentra 3.790 objetos con el patrón exacto descrito por RFC 9632: el atributo remarks:, el token Geofeed sensible a mayúsculas y una URL HTTPS. Cuando el análisis reconstruye cada objeto RPSL, aparecen 3.483 inetnum y 90 inet6num. Ese es el total de 3.573 objetos de direcciones.

Los otros 217 se reparten entre 168 objetos route, 41 route6, cinco domain, dos as-set y un organisation. La cadena cumple la forma textual. El objeto que la contiene no pertenece al ámbito de direcciones sobre el que la RFC organiza el descubrimiento.

No hay base para llamar fallos a esas 217 apariciones. Demuestran algo más básico: remarks: no conoce el tipo de lo que guarda. Puede contener una referencia Geofeed, una instrucción de soporte, un aviso o un bloque administrativo. El significado nace del acuerdo entre quien publica y quien analiza el texto. El esquema sólo ve una observación.

Por eso 3.573 encabeza este artículo. El total de 3.790 mide dónde aparece una cadena en todo RPSL. El total de 3.573 mide el conjunto pertinente para el mecanismo normalizado. Usar el primero como si fueran registros de direcciones añadiría una falsa precisión; ocultarlo borraría la evidencia de que el significado se ha derramado a otras clases.

El diseño vigente tiene una defensa sólida

AFRINIC no está usando una ocurrencia local fuera de la norma. Está usando la vía de compatibilidad que la norma reserva precisamente para esta situación.

RFC 9632 acepta que los RIR no cambien sus bases al mismo tiempo. Si geofeed: no existe, prescribe la forma estricta en remarks:. Hasta que todos los productores declaren que admiten el campo y los titulares hayan migrado sus objetos, los recolectores deben entender ambos formatos. Un cliente que elimine el soporte para las observaciones antes de esa evidencia sería incompatible, aunque su propio código pareciera más moderno.

La alternativa tiene escala operativa. Los 3.573 objetos de direcciones apuntan a 106 URL HTTPS distintas. Hay 3.461 objetos ASSIGNED PA, 71 ALLOCATED PA, 17 ALLOCATED-BY-RIR, 13 ASSIGNED PI y 11 SUB-ALLOCATED PA. Varios objetos pueden compartir una URL porque un operador mantiene un solo fichero para distintos prefijos.

Esos números no certifican que las URL respondan, que el contenido sea correcto ni que una plataforma concreta lo consuma. Sí prueban que la convención está implantada. Una migración que borre o modifique referencias sin preservar esta población podría hacer menos utilizable la base en nombre de una estructura más limpia.

También hay motivos legítimos para demorar. Un campo nuevo cambia la autenticación de actualizaciones, formularios, correo, volcado, clientes WHOIS, RDAP, validadores, documentación y soporte. Hay que resolver qué ocurre si conviven ambas formas, cómo se tratan variantes históricas y qué interfaz posee la autoridad final. Una línea en una plantilla puede esconder una migración de servicio completa.

La exigencia razonable, por tanto, no es una fecha impuesta. Es un estado público que permita saber si se está evaluando, aplazando, descartando o implementando el cambio.

La semántica tiene cuatro escalones

RFC 9632 señala que la forma en observaciones no puede ser comprobada formalmente por el RIR. La recomendación de no tener más de una referencia por objeto tampoco puede imponerse con limpieza cuando todo es texto. Un atributo propio puede validar HTTPS, controlar la cardinalidad, detectar duplicados y ofrecer una salida estructurada a otros protocolos.

La deriva ya es visible. Hay 3.592 objetos de direcciones con alguna observación parecida a Geofeed sin distinguir mayúsculas, y 106 líneas se apartan de la forma estricta. Algunas insertan dos puntos, otras usan minúsculas y otras recurren a HTTP. No sabemos qué variantes tolera cada consumidor. Sabemos que el esquema no puede rechazarlas por su significado.

Conviene ordenar las promesas de menor a mayor:

  1. El esquema puede afirmar que una cadena tiene una forma aceptable como referencia Geofeed.
  2. HTTPS puede proteger la conexión con el endpoint nombrado.
  3. Una firma RPKI opcional puede reforzar que el fichero está ligado a un certificado que cubre el recurso.
  4. Ninguna de esas capas demuestra por sí sola que cada lugar declarado sea real, actual y prudente desde el punto de vista de la privacidad.

HTTPS autentica el servidor web, no la autoridad sobre el espacio de direcciones. La firma RPKI opcional descrita por la RFC responde a esa diferencia. Aun así, vincular el fichero al recurso no convierte una ciudad o un código de país en observación física certificada.

El campo dedicado debe prometer menos para ser más útil: estructura, no omnisciencia. Puede ayudar a que la referencia sea corregible y coherente. No debe convertir a AFRINIC en garante de todos los datos de localización que transporta el fichero.

Esa es una lente distinta de la de un artículo previo sobre APNIC, que separó autenticación del enlace y verdad de la ubicación. Aquí el problema está un paso antes: la base AFRINIC aún no distingue estructuralmente el enlace de la prosa.

Del debate a un work item sin cierre visible

El 27 de octubre de 2025, un participante del Database Working Group propuso añadir geofeed: y permitir que los titulares de recursos lo actualizaran. Explicó que la alternativa era remarks: y relató que, en su experiencia con recursos PI, necesitaba ayuda del hostmaster.

Al día siguiente, el copresidente abrió dos semanas para comentarios y pidió al personal una evaluación con ventajas y desventajas. El 14 de noviembre, tras indicar que no había desacuerdo, solicitó a AFRINIC que tratara la propuesta como work item y explicara la implementación, incluida la evaluación de impacto.

El autor volvió a pedir atención el 6 de abril de 2026. El 16 de abril, el copresidente pidió confirmar que el trabajo seguía activo y reiteró la solicitud. Otro participante manifestó su apoyo el 17 de abril.

El índice oficial muestra meses con mensajes en enero, febrero, marzo, abril y agosto de 2026, sin archivos mensuales en mayo, junio o julio. En los hilos revisados hasta agosto no aparece un asunto Geofeed posterior al 17 de abril.

La constatación no debe crecer más allá de la prueba: no se encontró una respuesta o disposición posterior en el archivo público examinado. Eso no demuestra ausencia de ticket interno, análisis técnico, conversación privada ni dependencia externa. La lista no contiene toda la vida de AFRINIC.

La carencia es un objeto de cierre. Una petición pública puede acabar aceptada, aplazada, rechazada, absorbida por otro proyecto o pendiente de una condición. Cualquiera de esos estados puede ser defendible. Ninguno puede deducirse del silencio.

La muestra PI confirma un patrón, no una regla universal

El relato sobre recursos PI tiene un contraste limitado en los datos. Los 13 objetos de direcciones ASSIGNED PI que contienen la forma estricta incluyen AFRINIC-HM-MNT en mnt-by. También aparecen mantenedores ligados al recurso en atributos inferiores.

El patrón es compatible con una separación entre la protección del objeto y la gestión de datos más específicos. No explica todos los canales de actualización, excepciones de soporte o decisiones de autenticación. Trece casos no autorizan a decir que todo titular PI carece de capacidad de corregir la información.

La cuestión útil se expresa como una matriz: para cada clase, estado y relación entre mnt-by y mnt-lower, ¿quién puede añadir, cambiar, retirar y corregir la referencia? ¿Por qué interfaz? ¿Con qué credencial? Si no hay autorización directa, ¿qué canal interviene y qué número permite comprobar el resultado?

Publicar esa matriz no equivale a abrir la escritura. Hace visible cómo se protegen las modificaciones indebidas y cómo se evita que un dato viejo permanezca porque nadie conoce la ruta de corrección.

RDAP revela una migración semántica pendiente

La respuesta RDAP de AFRINIC para 160.115.0.0 incluye una URL Geofeed en la descripción general de observaciones. Su conformidad declara rdap_level_0, nro_rdap_profile_0 y cidr0. No declara geofeed1 ni ofrece un enlace estructurado.

RFC 9877 registra la relación rel: geofeed y la extensión opcional geofeed1. Un servidor puede devolver esos enlaces. Si anuncia la extensión, debe incluir el enlace cuando posee la URL y puede revelarla. Como AFRINIC no anuncia geofeed1 en el ejemplo, no hay una infracción demostrada.

Hay, en cambio, un coste de interfaz. Una persona reconoce la frase. Un recolector especializado también. Un cliente RDAP general no puede saber por la lista de conformidad que el servidor ofrece Geofeed estructurado ni obtener la relación estándar sin volver a analizar texto. El dato está presente; su tipo no ha atravesado el protocolo.

El recibo mínimo

Una decisión reproducible debería registrar:

  1. identificador, responsable, fecha de entrada, estado y próxima revisión del work item;
  2. versiones actual y prevista del esquema;
  3. impacto en actualización, volcado, WHOIS, RDAP y consumidores;
  4. permisos por clase, estado y mantenedor;
  5. sintaxis HTTPS, cardinalidad y errores;
  6. convivencia y precedencia entre ambas formas;
  7. inventario y tratamiento de registros estrictos, variantes y apariciones en otras clases;
  8. decisión sobre geofeed1 y salida RDAP;
  9. separación entre sintaxis, endpoint HTTPS, autoridad RPKI y exactitud;
  10. advertencia de privacidad y granularidad;
  11. cohorte de prueba, compatibilidad, corrección y reversión;
  12. recibo de despliegue o cierre con fecha, versión, métricas y excepciones.

El recibo no presupone que el campo deba llegar ahora. Puede justificar mantener la alternativa, validar primero nuevas observaciones, desplegar sin migración automática o aplazar RDAP. La rendición de cuentas no obliga a adoptar; obliga a que la decisión y sus límites sean visibles.

Una base registral gana confianza cuando sabe distinguir una estructura que valida de una declaración que sólo transporta. AFRINIC no necesita certificar la geografía de Internet africano. Necesita decir con precisión qué reconoce su libro, quién puede modificarlo y cómo se cierra una solicitud pública de cambio.