Resumen

  • La evaluación externa de compatibilidad vinculó sus observaciones a AFPUB-2019-V4-003-DRAFT02: ARIN y APNIC objetaron que el titular de origen tuviera que cumplir la política del RIR receptor; RIPE NCC rechazó que la solicitud comenzara en el registro receptor; LACNIC, aun sin exigir reciprocidad, señaló ambos desajustes.
  • El identificador y la fecha importan. Este Draft 2 fue presentado el 13 de agosto de 2020. El 8 de octubre de 2021 corresponde a AFPUB-2020-GEN-006-DRAFT02, una propuesta distinta cuya trayectoria no demuestra nada sobre la adopción o ejecución del texto analizado aquí.
  • El proyecto intentaba resolver una carencia real: habilitar transferencias inter-RIR de ida y vuelta, retirar límites cuantitativos y mantener comprobaciones de necesidad. Pero una promesa unilateral de portabilidad no crea el procedimiento que el otro registro necesita para reconocer el mismo cambio.
  • AFRINIC podía verificar su lado del expediente y coordinarse con un RIR compatible. Como llevador privado de registros técnicos, no podía dispensar el cumplimiento de las reglas de ARIN, APNIC, RIPE NCC o LACNIC, ni transformar el consenso aproximado condicional en una ruta operativa.
  • Una alternativa comprobable habría sido un certificado de compatibilidad ligado a una versión inmutable: por cada par y dirección, habría fijado recurso, condición, autenticador, punto de inicio, mensajes, actualización atómica, servicios dependientes, reversión y confirmación fechada de la contraparte.

L3 — Cuatro vías receptoras que no encajaban

La prueba más concreta no estaba en una declaración abstracta sobre la conveniencia de transferir direcciones. Estaba en una tabla que preguntó a cuatro registros si podían ejecutar el texto que AFRINIC tenía delante. La respuesta produjo cuatro fallos de acoplamiento. ARIN objetó la frase que obligaba al titular de origen a cumplir la política del RIR receptor. APNIC leyó el mismo requisito en los textos relevantes de Draft 2 y Draft 3 y concluyó que no era compatible, en especial por cargar al origen con reglas del receptor.

RIPE NCC se detuvo en otra parte: la sección 5.7.5 enviaba a la parte transferente a iniciar el trámite ante el RIR receptor, cuando el procedimiento de RIPE empezaba en el registro donde el recurso estaba inscrito. LACNIC no exigía reciprocidad, pero tampoco consideró sensato imponer al origen la política ajena y observó que aquel inicio en el receptor no coincidía con los demás arreglos inter-RIR.

La imagen que deja el expediente es precisa. AFRINIC había proyectado un carril que parecía abierto desde su propia orilla, mientras cada contraparte encontraba que la pieza de unión no coincidía con su procedimiento. Ninguna de esas respuestas decía que la gerencia de AFRINIC pudiera salvar el paso otorgando un permiso excepcional. Decían algo más sobrio y más exigente: la transferencia solo podría adquirir una forma registral única si las reglas y los actos de ambos lados aceptaban la misma secuencia.

Antes de examinar esa secuencia conviene fijar la pieza documental. AFPUB-2019-V4-003-DRAFT02 era la versión 2.0 de Resource Transfer Policy, presentada el 13 de agosto de 2020 para modificar la sección 5.7 del Consolidated Policy Manual. Una ficha de planificación le había adherido por error el 8 de octubre de 2021. Esa fecha corresponde a AFPUB-2020-GEN-006-DRAFT02, perteneciente a otra propuesta de transferencia de recursos numéricos. Identificador y fecha no son adornos bibliográficos: determinan qué frases evaluaron las contrapartes, qué procedimiento estaba en discusión y qué conclusión de compatibilidad puede sostenerse.

La distinción impide un atajo retrospectivo. El Draft 2 de 2020 fue propuesto, discutido, evaluado y más tarde archivado. La página oficial lo identifica hoy como archivado, pero ese estado conserva un expediente; no prueba que el texto entrara en el manual, que fuera ratificado ni que llegara a operar en producción. El anuncio del 21 de septiembre de 2020 habló de consenso aproximado condicional y de último llamado, señaló una preocupación de reciprocidad vinculada con ARIN y requirió enmiendas. Aquello era un momento del procedimiento de discusión. No equivalía a adopción, ratificación o implementación.

Que a continuación apareciera otra versión tampoco reescribe la condición de Draft 2.

La misma cautela se aplica al otro linaje. El 4 de febrero de 2026 AFRINIC anunció la ratificación de AFPUB-2020-GEN-006-DRAFT03. Esa noticia pertenece a una propuesta separada y no puede proyectarse hacia atrás para afirmar que AFPUB-2019-V4-003-DRAFT02 obtuvo vigencia. En este asunto, mezclar fechas haría algo peor que confundir una cronología: convertiría una evaluación de interfaz sobre un texto exacto en una supuesta aprobación de otro texto.

Lo que Draft 2 trató de ordenar

El punto de partida era razonable. La política existente no ofrecía, según la propuesta, un mecanismo inter-RIR en dos sentidos. Draft 2 pretendía permitir movimientos dentro de la región de servicio de AFRINIC, hacia ella y desde ella. El planteamiento del problema nombraba tanto direcciones IPv4 como números de sistema autónomo. En un entorno de escasez, una organización que obtiene recursos de otra parte necesita que la transferencia sea reconocida por los registros pertinentes, no solo que exista un acuerdo privado entre vendedor y receptor.

El proyecto definía como origen al titular vigente de los derechos sobre recursos IPv4 registrados en cualquier RIR. A ese origen le exigía cumplir las políticas del RIR receptor. Para una transferencia que entrara desde otro RIR a AFRINIC, mantenía una evaluación de necesidad: AFRINIC debía aprobar la necesidad de IPv4 del receptor conforme a las políticas vigentes. Para una salida desde AFRINIC hacia otro registro, el movimiento debía seguir la política del RIR receptor.

La propuesta aceptaba como receptor a cualquier parte que alcanzara un acuerdo de transferencia con el remitente, aunque la evaluación de personal interpretó que un receptor en la región de AFRINIC necesitaría membresía y un examen de necesidad.

Draft 2 también retiraba las esperas existentes de doce meses y no establecía un límite superior para el volumen de una transferencia, asignación o adjudicación cuando remitente y receptor tuvieran un acuerdo mutuo, siempre sujeto a la política aplicable. Disponía que los recursos IPv4 heredados dejarían de considerarse heredados después de ser transferidos. Estos detalles no eran periféricos. El volumen, la condición de legado y el examen de necesidad afectan qué estado espera registrar cada lado y, por tanto, qué significa que ambos hayan aceptado el mismo movimiento.

La secuencia propuesta parecía lineal. La parte transferente enviaría una solicitud al RIR receptor mediante una plantilla estándar y un acuerdo oficial de transferencia. Tras aprobarla, el receptor notificaría al RIR de origen, al titular de origen y al destinatario; entonces se efectuaría el traslado. El texto comprimía en una sola línea varias preguntas que, entre registros independientes, no pueden darse por resueltas: quién tiene capacidad para autenticar al titular actual, quién determina si el recurso está libre de disputa, qué evidencia circula y en qué instante cada registro cambia su copia autoritativa.

AFRINIC detectó el problema en su propia evaluación. Su personal preguntó por qué un titular debería cumplir la política de un RIR receptor con el que no tenía relación. También advirtió que no podría verificarse al titular si este presentaba la solicitud directamente ante el receptor en vez de hacerlo ante el RIR que conservaba su inscripción. La objeción no era una preferencia administrativa menor. El registro de origen posee la relación documental y la posición registral desde las que puede comprobar que quien pide mover el bloque es quien figura como titular autorizado.

El receptor puede evaluar a su futuro miembro o cliente, pero una oración de AFRINIC no le entrega por sí sola las pruebas que custodia otro registro.

Había más costuras abiertas. El personal preguntó si la llamada plantilla estándar gozaba de aceptación mundial. No encontró una pauta para recursos disputados. Alertó sobre la posibilidad de abuso mediante asignaciones repetidas. Identificó una contradicción entre las cláusulas 5.7.4.1 y 5.7.4.2 acerca del receptor. Y señaló que los ASN aparecían en el resumen del problema, aunque las disposiciones operativas se referían a IPv4, una diferencia capaz de generar confusión sobre qué clase de recurso entraba realmente en el mecanismo.

Cada observación revela por qué la compatibilidad debe ser granular. Un texto puede ser compatible para una entrada de IPv4 y no decir bastante sobre una salida de ASN. Puede admitir una transferencia ordinaria y dejar sin tratamiento un prefijo disputado. Puede coincidir con la política sustantiva de una contraparte, pero arrancar el procedimiento en una mesa que no dispone de la evidencia necesaria. Decir que existe una política de transferencias no responde a ninguna de esas preguntas.

ARIN y APNIC: la obligación colocada en el lado equivocado

La evaluación externa dejó expresamente atada su columna de Draft 2 al identificador AFPUB-2019-V4-003-DRAFT02. Esa vinculación protege la interpretación contra el traslado descuidado de una respuesta a versiones posteriores. ARIN consideró incompatible con su política inter-RIR la frase según la cual el origen debía cumplir la política del RIR receptor. APNIC concluyó asimismo que Draft 2 y Draft 3 compartían el texto relevante y que no eran compatibles, sobre todo por esa misma exigencia.

La objeción puede parecer paradójica. Si el recurso llega al receptor, ¿por qué no pedir que todas las partes obedezcan las reglas del receptor? Porque cada política distribuye funciones entre sujetos que mantienen relaciones diferentes con cada registro. El titular de origen está inscrito en su RIR de partida. El receptor se presenta ante el RIR de destino. Hacer que el origen satisfaga requisitos concebidos para el destinatario puede imponerle obligaciones que no corresponden a su vínculo y, a la vez, dejar sin resolver la autenticación que sí corresponde al registro de partida.

Una regla genérica de cumplimiento no crea una cadena de custodia documental.

Tampoco era posible que AFRINIC declarara compatible esa frase por voluntad propia. ARIN y APNIC son coordinadores privados independientes con textos y procedimientos propios. AFRINIC podía ajustar su propuesta, pedir confirmación y preparar sus sistemas para una vía aceptada por ambos extremos. No podía dispensar una exigencia de la contraparte, reinterpretarla de manera vinculante o mandar que la otra organización reconociera una operación que su procedimiento no podía ejecutar.

RIPE NCC: la solicitud empezó donde no estaba el registro

RIPE NCC enfocó la sección 5.7.5. La consideró incompatible y no implementable porque Draft 2 ordenaba a la parte transferente comenzar ante el RIR receptor, mientras el procedimiento de RIPE empezaba en el RIR donde los recursos estaban registrados en ese momento. El desajuste convertía una instrucción aparentemente práctica —«envíe aquí la solicitud»— en un fallo de control.

El registro que conserva la inscripción de origen está en condiciones de autenticar la cuenta, revisar la autoridad de quien actúa y confirmar la condición actual del recurso. Si el primer acto se presenta en otro lugar, el receptor debe confiar en evidencia que todavía no ha validado el custodio correspondiente o diseñar un rodeo para pedir esa validación. El resultado no es necesariamente una transferencia fallida —el expediente no documenta una operación concreta ni un rechazo consumado—, pero sí una ruta que las dos instituciones no podían describir como el mismo procedimiento ejecutable.

El orden importa también al final. Una transferencia entre registros no queda completa porque dos bases muestren cambios aproximados. Debe existir un punto de aceptación compartido y una secuencia en la que una inscripción deje de ser autoritativa al mismo tiempo que la otra adquiere esa condición, con los servicios dependientes acompasados. Si el primer mensaje ya parte de premisas distintas, el último difícilmente puede ser unívoco sin un acuerdo adicional.

LACNIC: no exigir reciprocidad no elimina el empalme

La respuesta de LACNIC aclara otra posible confusión. LACNIC no demandaba reciprocidad, pero aun así consideró poco sensato exigir que el origen cumpliera la política del otro RIR y observó que iniciar por el receptor no coincidía con otros arreglos inter-RIR. La ausencia de una condición de reciprocidad no significaba disponibilidad para aceptar cualquier secuencia. Solo eliminaba una barrera concreta; permanecían la distribución de responsabilidades y el método de autenticación.

Ese matiz derriba la idea de que bastaba con encontrar una contraparte más flexible. Incluso cuando un registro no exigía simetría normativa, necesitaba saber quién verificaba al titular, dónde empezaba el expediente y cómo pasaba la confirmación de una institución a la otra. La flexibilidad sustantiva no sustituye un protocolo de entrega.

Las cuatro respuestas deben leerse como fotografías fechadas de la relación entre textos concretos, no como juicios eternos sobre los registros. ARIN, APNIC, RIPE NCC o LACNIC podían cambiar después su política o su operación; Draft 2 podía ser enmendado. Ninguno de esos cambios futuros modifica lo que la evaluación encontró en la versión presentada el 13 de agosto de 2020. La compatibilidad vive en la intersección de dos versiones y una fecha, no en el nombre genérico de una institución.