Resumen

  • El acta de AFRINIC-37 sitúa después de MyAFRINIC v2 la implementación completa de los ROA AS0, el sistema técnico de transferencias y el trabajo interno sobre el contacto de abuso; una evaluación distinta coloca en la misma secuencia una propuesta AS-SET que seguía en Last Call.
  • No es una cartera de cuatro funciones equivalentes. Hay tres políticas ratificadas y una propuesta; intervienen RPKI, acuerdos procedimentales con otros RIR, validación y aviso, WHOIS e IRR.
  • El lanzamiento del portal sólo demuestra el estado del portal. Para demostrar implementación hacen falta actas de aceptación separadas que unan texto y versión, baseline técnica, casos de prueba, población UAT/beta, activación, excepciones y evidencia posterior.
  • Concentrar trabajo en una base común puede eliminar duplicidades y reglas heredadas incompatibles. La concentración se vuelve riesgo cuando un anuncio general permite que lo listo, lo parcial, lo pendiente y lo no ratificado reciban una misma etiqueta.

Las fechas son una moneda cómoda en los proyectos institucionales. Permiten ordenar presupuestos, recursos humanos, pruebas y comunicación. También permiten explicar una dependencia compleja con una frase: esto ocurrirá después de aquello. El problema aparece cuando la fecha deja de describir el orden de trabajo y empieza a servir como prueba del resultado.

Eso es lo que debe evitar AFRINIC alrededor de MyAFRINIC v2. Sus documentos públicos no demuestran que el portal haya fallado, que haya incumplido un plazo ni que un miembro haya sufrido un daño. Demuestran algo anterior: cuatro trayectorias de política han quedado conectadas a un mismo hito de software, aunque no tengan la misma autoridad ni el mismo mecanismo de impacto.

Una de ellas busca publicar ROA AS0 para espacio no asignado y no adjudicado. Otra debe hacer operativa una política de transferencia que incluye rutas entre registros. La tercera debe convertir una obligación de contacto de abuso en validación, aviso y corrección. La cuarta restringiría los nombres de nuevos AS-SET a formas jerárquicas, pero aún era una propuesta en Last Call en las fuentes comprobadas.

Por eso, la pregunta no es si MyAFRINIC v2 “incluye las cuatro políticas”. Esa formulación confunde interfaz, sistema, procedimiento y autoridad. La pregunta útil es qué evidencia independiente debe completar cada trayectoria para que AFRINIC pueda afirmar, sin exceso, que la política opera.

Dos relojes de calendario y ninguno de aceptación

El acta de AFRINIC-37, reunión celebrada el 24 de junio de 2026, dice que el desarrollo de MyAFRINIC v2 comenzó en 2020. Tras restricciones presupuestarias y de recursos durante varios años, el proyecto fue reactivado. En junio, la expectativa era ponerlo en marcha antes del final de 2026. Para cumplirla, era necesario limitar el alcance y evitar scope creep.

El control del alcance es compatible con una buena decisión de producto. Un portal que toca identidades, autorizaciones, registros técnicos y trabajo interno puede ganar seguridad si libera primero una base coherente y pospone elementos que no han pasado pruebas. La infraestructura compartida también puede impedir que una misma regla se interprete de forma distinta en sistemas antiguos. Pero el acta no identifica una función concreta retirada del alcance.

No permite decir que una de las cuatro trayectorias fue sacrificada.

La página de AFRINIC en AfPIF 2026 describe MyAFRINIC v2 como una reconstrucción completa del portal de autoservicio. Solicitaba comentarios antes de las pruebas de aceptación de usuarios y una live beta. Pedía contactos para participar y entrevistas sobre flujos diarios. Es una señal clara de preparación. No acredita UAT finalizada, beta iniciada o terminada, ni producción general.

La evaluación de la propuesta AS-SET aporta una fecha más estrecha: 15 de noviembre de 2026. Su plan dice que los recursos estaban canalizados hacia MyAFRINIC v2 y que la propuesta sería priorizada cuando concluyera esa implementación. El acta de junio habla, en cambio, del final del año. No hay que corregir una fuente con la otra. Hay que conservar ambas: una fecha específica dentro de una evaluación y una expectativa más amplia dentro de un informe de estado.

Ninguna es una fecha universal de las cuatro políticas. Tampoco es evidencia de situación actual. En la fecha de corte, el 15 de noviembre aún estaba por llegar. Hablar de incumplimiento sería inventar un hecho; hablar de implementación conjunta sería inventar cuatro.

AS0 y la obligación de explicar lo parcial

El registro de políticas vigente presenta AFPUB-2019-GEN-006-DRAFT03, RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space, como ratificada y Awaiting Implementation. El acta añade estados intermedios. La implementación se estaba probando internamente con una evolución de KRILL. Se esperaba una beta a final de mes que sería anunciada como partly implemented. La implementación íntegra, según el texto, dependía de MyAFRINIC v2.

La secuencia ya desmiente cualquier estado binario. Ratificación no es prueba interna; prueba interna no es beta; beta parcial no es aplicación completa del texto. Cada paso responde a una pregunta diferente.

La aceptación de AS0 debería señalar objetos y cobertura. Debe mostrar qué espacio entra en el alcance, qué queda fuera, cómo se reconoce un fallo de publicación, cómo se corrige y qué condición hace que el estado deje de ser parcial. Las fuentes revisadas no aportan esa matriz ni prueban que la beta proyectada se materializara. No corresponde rellenar ese silencio.

Sí corresponde exigir que el registro futuro conecte la versión ratificada, la baseline de MyAFRINIC v2, el estado pertinente de KRILL, los casos de prueba y la operación posterior. Partly implemented es una etiqueta honesta sólo cuando incluye una lista de lo presente, lo ausente y la salida prevista. Sin eso puede convertirse en una categoría indefinida.

Transferencias y el extremo que no está en el portal

La síntesis de políticas ratificadas fecha el 4 de febrero de 2026 la ratificación de Number Resources Transfer Policy AFPUB-2020-GEN-006-DRAFT03. El acta de AFRINIC-37 dice que cubre transferencias intra-RIR e inter-RIR y que, en abril de 2026, se había confirmado reciprocidad con los otros cuatro RIR. Member Services estaba coordinando con sus homólogos para trazar los procedimientos.

La implementación técnica se priorizaría después de MyAFRINIC v2.

El extremo visible de una transferencia puede ser una solicitud dentro del portal. El otro extremo puede estar en otra institución. Entre ambos hay elegibilidad, documentos, estados, decisiones y actualizaciones de registro. Por ello, un formulario operativo no demuestra una ruta operativa. Una ruta exige una prueba de extremo a extremo para cada categoría que realmente pueda utilizarla.

También es posible el estado inverso: procedimientos acordados y trabajo manual disponible antes de una interfaz general. Afirmar “no implementado” sólo por ausencia del portal borraría ese avance. Una ficha de aceptación debe admitir descripciones más precisas: procedimiento mapeado, contraparte preparada, prueba técnica pendiente; ruta habilitada para una categoría, no para otra; interfaz limitada mientras se valida el resultado de registro.

El acta debería identificar el requisito previo, la contraparte, el caso probado, el punto de decisión, la notificación y la forma de reanudar o corregir una operación. El primer caso real, cuando exista y sea publicado, demostrará ese caso. No demostrará todas las rutas por contagio.

Abuse contact y la falsa simplicidad de un correo

La misma síntesis fecha el 4 de febrero de 2026 Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07. El acta dice que la implementación técnica en sistemas internos se priorizaría una vez completado el despliegue de MyAFRINIC v2.

El objeto de aceptación no puede ser sólo que existe abuse-c, ni que una aplicación sabe enviar correo. La política se vuelve flujo cuando define qué registro se comprueba, quién recibe qué aviso, qué cuenta como respuesta o fallo, cuánto tiempo existe para corregir, qué excepción se admite y desde qué evento se produce una consecuencia.

Además, la versión importa. Una pieza anterior de BTW estudió un Draft 2 antiguo y su cadena de consecuencias. Esa cadena no puede importarse en Draft 7 por comodidad. El sistema debe mostrar que la lógica que opera deriva del texto ratificado. Las instrucciones internas pueden concretarlo; no pueden sustituirlo sin rastro.

Un estado parcial puede cubrir nuevos solicitantes sin haber recorrido registros existentes, o puede enviar avisos sin haber aceptado el camino de corrección. Puede haber procedimiento interno antes de interfaz de miembro. Ninguno de estos estados es necesariamente impropio. Lo impropio sería llamarlos a todos “implementación” sin declarar el límite.

AS-SET y el umbral que el software no puede cruzar

AFPUB-2026-ASN-001-DRAFT02 no comparte el estado jurídico de las anteriores. El registro la sitúa en Last Call. No hay ratificación en las fuentes congeladas. La evaluación de personal señala que todos los puntos de creación WHOIS y la interfaz IRR de MyAFRINIC requerirían cambios para impedir nuevos nombres AS-SET no jerárquicos. Los objetos existentes no serían renombrados.

Una evaluación previa es una parte sana del proceso. Permite discutir viabilidad, impacto y recursos antes de una decisión. Pero no confiere autoridad a la regla. Mientras el texto siga siendo propuesta, el estado correcto es evaluación y preparación. Si llega la ratificación, la aceptación debe empezar por la versión final y la fecha efectiva.

Después será necesario recorrer cada punto de creación. El rechazo en la interfaz del portal no prueba el control en otros caminos WHOIS. La creación correcta de un objeto nuevo tampoco prueba que los objetos antiguos permanezcan intactos. La propuesta establece dos bordes —nuevas creaciones y preservación de las antiguas— que exigen pruebas diferentes.

Trayectoria Estado comprobado Relación con MyAFRINIC v2 Prueba de aceptación pendiente
ROA AS0 Ratificada; Awaiting Implementation; prueba interna y beta parcial proyectada Aplicación completa del texto dependiente del portal Objetos, cobertura, definición parcial/completa, corrección, activación y evidencia continua
Transferencias Ratificada el 4 de febrero de 2026; mapeo de procedimientos en marcha Sistema técnico priorizado después del portal Pruebas por ruta y contraparte, decisión, actualización de registro, aviso y reparación
Contacto de abuso Ratificada el 4 de febrero de 2026 Técnica interna después de completar el portal Vínculo a Draft 7, pruebas de validación/aviso/corrección, excepciones y frontera de consecuencias
AS-SET jerárquico Propuesta en Last Call Cambios WHOIS/portal evaluados y trabajo posterior al portal Ratificación, texto efectivo, cobertura de todos los accesos, preservación y corrección de objetos antiguos

Una homologación por política

AFRINIC no necesita abrir el código, los expedientes de miembros ni los tickets internos. Necesita una tabla estable, con eventos añadidos en vez de estados reescritos.

La primera columna debe fijar autoridad: título, identificador, versión y estado. Impide que una aplicación construida durante una consulta termine atribuida al borrador equivocado. Mantiene AS-SET como propuesta hasta que exista otro acto.

La segunda debe fijar la baseline técnica. MyAFRINIC v2 es un nombre de programa, no un estado reproducible. Hace falta una versión, una entrega fechada o un identificador suficiente para saber qué se probó. El cambio posterior debe añadir una entrada; no debe alterar la historia de la primera aceptación.

La tercera debe clasificar la dependencia: interfaz, WHOIS, IRR, RPKI, workflow interno, migración o procedimiento con otra institución. Esa clasificación evita que una página visible reciba mérito por una lógica no probada detrás de ella.

Luego vienen requisito previo, responsable, caso de prueba y criterio. Atribuir no equivale a culpar. Registry Products puede acreditar la baseline; Member Services, el procedimiento; un equipo operativo, la publicación o validación; el órgano competente, la autoridad del texto.

La población de prueba también importa. La prueba interna examina la lógica. UAT examina permisos y tareas de miembros. La beta observa interacciones en un entorno más próximo a la operación. Una invitación a participar no es un resultado, y un resultado de laboratorio no responde por la experiencia de un miembro.

Por último, la ficha debe definir parcial y completo, registrar aviso y activación, describir excepción, rollback y corrección, y nombrar la ventana de observación. La disponibilidad del portal es una métrica de producto. La política requiere un resultado propio: cobertura y corrección AS0, ruta de transferencia, estados de validación o cumplimiento de una regla en todos los accesos.

Lo que todavía no se sabe

Los documentos no demuestran que MyAFRINIC v2 esté en producción, que UAT o beta hayan terminado, que AS-SET se haya ratificado, ni que AS0, transferencias o abuse contact estén completamente implementados. Tampoco establecen una caída, un plazo incumplido, una prueba fallida, una transferencia rechazada, un contacto inválido, una colisión AS-SET o un efecto de enrutamiento RPKI.

No hay, en este expediente, un miembro perjudicado por la dependencia común. Inventarlo convertiría una arquitectura de control en una acusación sin prueba.

AFRINIC ya ha publicado un vocabulario más fino: Awaiting Implementation, prueba interna, partly implemented, mapeo procedimental, prioridad posterior al portal y Last Call. Ese vocabulario puede convertirse en un registro de homologación si se une a versiones, pruebas y correcciones.

Entonces MyAFRINIC v2 podrá prestar infraestructura a cuatro políticas sin prestarles una conclusión que cada una debe ganar por separado.

Fuentes