Resumen

  • El archivo mensual y la ficha oficial de AFRINIC registran AFPUB-2009-ASN-001 como «Implemented» el 26 de mayo de 2010. Ese dato prueba una clasificación pública y la conclusión de una etapa regional; no identifica por sí solo una modificación de software, una transacción con IANA ni un cambio experimentado por un miembro.
  • La secuencia contemporánea impide confundir esa fecha con la vigencia global. Una presentación oficial de AFRINIC-12 indicó que la propuesta ya había pasado por las cinco regiones, pero todavía no había sido trasladada formalmente del NRO-EC al ASO-AC. Ese envío ocurrió el 13 de julio, el ASO-AC la remitió a ICANN el 22 de julio e ICANN la ratificó el 21 de septiembre.
  • La enmienda era estrecha: prolongaba hasta el 31 de diciembre de 2010 la distinción entre inventario de ASN de 16 bits e inventario utilizable solo como ASN de 32 bits; desde el 1 de enero de 2011 debía operar un fondo indiferenciado. Su razón práctica era dar tiempo a una compatibilidad que la declaración institucional no podía fabricar.
  • La lectura defendible trata el 26 de mayo como un acto regional acotado de contabilidad y coordinación. Un registro puede preparar procedimientos y anunciar que ha completado su parte antes del cierre mundial, pero una constancia sólida debería separar aprobación, publicación, vigencia, despliegue, transacción y resultado operativo, y acompañar cada capa con evidencia observable.

El día en que una palabra adelantó al procedimiento

El expediente público contiene una tensión poco habitual por su nitidez. En el archivo de noticias de 2010 de AFRINIC aparece, con fecha 26 de mayo, la propuesta AFPUB-2009-ASN-001. La página canónica repite tanto el estado «Implemented» como esa fecha. Su historial registra además que el Consejo de AFRINIC la aprobó el 25 de mayo. Si se leyera únicamente esa ficha, sería razonable concluir que la organización había cerrado la cuestión dentro de su propio ámbito.

Sin embargo, una presentación oficial del NRO-NC y ASO-AC durante AFRINIC-12 describió un proceso mundial que aún no había llegado a su tramo formal final. Según aquella exposición, la propuesta había superado los procesos regionales en 2009 y 2010 y el Consejo de AFRINIC la había ratificado en mayo, pero todavía no había pasado formalmente del Consejo Ejecutivo de la NRO al Consejo de Direcciones de la ASO.

Meses después, ICANN informó de esos pasos: el NRO-EC remitió la propuesta al ASO-AC el 13 de julio; el ASO-AC la envió al Consejo de ICANN el 22 de julio; hubo un periodo final de comentarios; y el Comité Ejecutivo del Consejo de ICANN la ratificó el 21 de septiembre. El anuncio de septiembre añadió que el personal tomaría las medidas necesarias para implementarla.

Estas dos piezas no se anulan. Describen capas diferentes. La ficha de AFRINIC acredita que el registro calificó su paso regional como implementado el 26 de mayo. La presentación de AFRINIC-12 y la documentación posterior de ICANN acreditan que la cadena mundial no se había completado entonces. El error empezaría al hacer que una de esas afirmaciones ocupara el lugar de la otra: decir que nada ocurrió el 26 de mayo borraría un acto institucional documentado; decir que ese día cambió la regla global de asignación de IANA inventaría un efecto que la cronología contradice.

La pregunta pertinente, por tanto, no es si la palabra «implementada» estaba permitida en abstracto. Es qué estado observable nombraba. Podía designar la conclusión del ciclo regional, la publicación de un texto operativo, la disponibilidad interna para actuar cuando la cadena superior quedara cerrada o algún cambio de procedimiento ya efectivo dentro de AFRINIC. Los documentos recuperados no permiten escoger entre esas posibilidades con precisión. Sí permiten excluir la más amplia: AFRINIC no ratificó por sí sola la política global ni convirtió el 26 de mayo en fecha mundial de efecto.

La enmienda, sin convertirla en una historia general de los ASN

Un número de sistema autónomo, o ASN, identifica de forma única a una red conectada con más de otra red y capaz de controlar su propia política de encaminamiento. Para este caso basta esa definición. La controversia no requiere reconstruir la historia completa de esos números ni los mecanismos técnicos de transición. Requiere entender una distinción de inventario y el aplazamiento de su fecha límite.

AFPUB-2009-ASN-001 prolongaba un año el periodo durante el cual IANA y los registros regionales distinguían entre existencias de ASN de 16 bits y existencias de ASN que solo podían utilizarse como números de 32 bits. La separación debía mantenerse hasta el 31 de diciembre de 2010. A partir del 1 de enero de 2011, las asignaciones debían proceder de un fondo indiferenciado de ASN de 32 bits. No alteraba aquí el centro del análisis ningún tamaño de bloque, umbral de reposición ni fórmula de demanda; el cambio relevante era la prórroga de esa distinción temporal.

La razón operativa era concreta. La adopción de ASN de 32 bits avanzaba más despacio de lo previsto, y todavía había sistemas que no podían utilizar sin fricción todo el espacio ampliado. La existencia nominal de inventario no equivalía necesariamente a inventario compatible con las redes que pedían recursos. Sin una prórroga, un registro podía parecer abastecido en cifras agregadas y, al mismo tiempo, afrontar escasez de números utilizables por solicitantes dependientes de compatibilidad heredada. Esa diferencia entre abundancia contable y utilidad efectiva era el riesgo que la enmienda intentaba administrar.

Pero la necesidad práctica no simplificaba la cadena institucional. El texto debía recorrer los procedimientos regionales de los cinco RIR y después avanzar por la NRO, la ASO e ICANN antes de convertirse en política global aplicable a IANA. La coordinación se componía de actos sucesivos, no de un único momento creador. Cada organización podía completar su propio trabajo, pero ninguna etiqueta regional podía sustituir los actos pendientes de las demás.

La compatibilidad también impone una prueba de realidad. Una fecha puede autorizar a un equipo a mantener dos clases de inventario; no puede hacer que un equipo de red, una aplicación o un proceso empresarial acepte lo que antes rechazaba. La disponibilidad operativa pertenece al código en ejecución, a las prácticas de los operadores y a las transacciones que efectivamente se completan. La declaración importa porque ordena expectativas y procedimientos, pero no produce por sí sola interoperabilidad.

Una cronología que debe conservar sus discrepancias

El historial regional comienza el 28 de agosto de 2009, cuando AFRINIC registró la presentación de la propuesta en su lista RPD. El 27 de noviembre, durante AFRINIC-11, se anotó consenso regional. Esa decisión es un antecedente indispensable, pero no el centro de este caso. Acredita un juicio técnico dentro del proceso de AFRINIC; no demuestra asentimiento de todos los operadores, representación democrática de África ni un mandato soberano.

Incluso antes de mayo aparecen fechas que no encajan de forma perfecta. AFRINIC sitúa su última convocatoria entre el 4 y el 19 de diciembre de 2009, mientras que ICANN registra un intervalo entre el 2 y el 17 de diciembre. La documentación disponible no explica la diferencia. No procede corregirla por intuición, fusionar ambos intervalos ni convertirla en indicio de conducta impropia. Lo correcto es preservar cada atribución y reconocer que el motivo sigue desconocido.

La secuencia decisiva se concentra entre el 24 y el 26 de mayo de 2010. El informe de antecedentes de ICANN dice que el Consejo de AFRINIC adoptó la propuesta el 24 de mayo. El historial de AFRINIC dice que su Consejo la aprobó el 25. El archivo y la página de política de AFRINIC fijan el estado implementado en el 26. No hay base para tratar las tres fechas como sinónimos. Tampoco hay evidencia suficiente para determinar si la divergencia entre 24 y 25 corresponde a husos horarios, sesiones distintas, redacción posterior, una decisión y su formalización u otra causa.

En el encuentro AFRINIC-12, celebrado entre finales de mayo y comienzos de junio, la presentación oficial de la estructura NRO-NC/ASO-AC dejó una frontera contemporánea. La propuesta había pasado por todas las regiones y el Consejo de AFRINIC la había ratificado, pero el traslado formal del NRO-EC al ASO-AC seguía pendiente. Esa exposición es especialmente valiosa porque no reconstruye retrospectivamente el proceso tras su conclusión: muestra cómo se describía el estado de la cadena cuando la etiqueta regional acababa de publicarse.

El 13 de julio, el NRO-EC envió la propuesta final al ASO-AC para su verificación procedimental. El 22 de julio, el ASO-AC la remitió al Consejo de ICANN. ICANN abrió después un periodo final de comentarios del 23 de julio al 13 de agosto. El 21 de septiembre anunció que el Comité Ejecutivo de su Consejo había ratificado la política global y señaló que el personal emprendería los pasos necesarios de implementación. La redacción confirma que, para ICANN, todavía existía trabajo posterior a la ratificación.

La fecha exacta en que el proceso productivo de IANA reflejó el texto final no aparece en los documentos examinados. El texto definitivo prueba el contenido global de la prórroga, y el anuncio del 21 de septiembre prueba la ratificación y la instrucción de proceder. Ninguno aporta por sí mismo una transacción fechada, un cambio de configuración o una primera asignación que cierre empíricamente la implementación de servicio.

El 11 de noviembre de 2010, AFRINIC implementó un texto posterior sobre su proceso de desarrollo de políticas. Ese documento distinguía expresamente aprobación e implementación y pedía anunciar las fechas de adopción e implementación. Sirve como contexto para comprender que AFRINIC podía concebir ambas como etapas distintas. No puede proyectarse hacia atrás como si fuera la regla demostrada que gobernó el acto de mayo, porque él mismo entró en vigor meses después.

Seis capas, seis preguntas distintas

La palabra «implementación» puede abarcar demasiado si no lleva apellido. Una prueba ordenada separa al menos seis capas. La primera es la conclusión de la gobernanza regional: ¿el proceso técnico regional tomó y publicó una decisión? En este caso, el consenso registrado en noviembre de 2009, la posterior aprobación del Consejo y el estado del 26 de mayo permiten responder afirmativamente, con las discrepancias de fecha ya señaladas. Esa conclusión no equivale a consentimiento general ni a autoridad pública.

La segunda capa es la preparación del procedimiento operativo regional: ¿AFRINIC había ajustado instrucciones, formularios, clases de inventario, controles internos o formación para sostener la prórroga? Es posible y resulta coherente con la defensa más fuerte de la etiqueta, pero el registro público consultado no identifica cuál de esos elementos cambió. La publicación de la norma no sustituye la evidencia de la preparación, aunque pueda ser uno de sus componentes.

La tercera capa es la ratificación de la política global: ¿habían terminado los actos comunes de NRO, ASO e ICANN? El 26 de mayo la respuesta era no. La presentación de AFRINIC-12 lo señaló en tiempo real, y las fechas de julio y septiembre muestran cuándo avanzaron los pasos faltantes. No existe base para atribuirles efecto retroactivo por el solo hecho de que todas las regiones ya hubieran aceptado la propuesta.

La cuarta capa es el cambio del proceso de IANA: ¿la entidad encargada de la asignación superior modificó su práctica productiva conforme al texto ratificado? El anuncio de ICANN dice que su personal tomaría medidas, pero no facilita el momento exacto, el cambio aplicado ni una constancia de despliegue. Por eso, ratificación e implementación de IANA deben permanecer en columnas separadas.

La quinta capa es la transacción observada: ¿una solicitud o asignación concreta se procesó de forma diferente a causa de la prórroga? No se ha recuperado un expediente anonimizado de petición, una entrega de IANA a AFRINIC ni un registro de antes y después que lo demuestre para el 26 de mayo. Sin esa pieza, puede afirmarse la intención del procedimiento y su clasificación pública, no un resultado transaccional particular.

La sexta capa es el desenlace para el operador: ¿una red africana obtuvo un ASN compatible, evitó una interrupción o cambió su despliegue gracias a la enmienda? La justificación de la política demuestra que existían riesgo de compatibilidad y tensión entre clases de inventario. No identifica qué operador se benefició, cuánto costó adaptarse ni qué fallo se evitó. La ausencia de nombres o cantidades no invalida la política; limita el alcance de cualquier afirmación sobre su impacto realizado.

Separar las capas evita dos errores opuestos. Uno es exigir una captura de tráfico para reconocer cualquier acto institucional y acabar negando la realidad de una decisión publicada. El otro es aceptar una etiqueta administrativa como prueba suficiente de cada consecuencia técnica posterior. El estándar razonable concede a cada documento exactamente el valor que tiene: un acta prueba una decisión; una página de estado prueba una clasificación; un cambio de procedimiento prueba preparación; una traza de transacción prueba ejecución; una medición de servicio prueba resultado.

Lo que sí ocurrió el 26 de mayo

AFRINIC terminó y expuso públicamente una etapa de su ciclo regional. El acto hizo definitiva, dentro de su registro documental, la posición de AFRINIC sobre la prórroga. Publicó el texto aplicable, su fundamento, los argumentos contrarios y una historia del proceso. También comunicó a empleados, miembros y socios de coordinación que la organización ya no trataba la cuestión como una propuesta regional pendiente.

Ese cambio de estado podía producir efectos antes de cualquier paquete o asignación. El personal podía organizar su trabajo conforme a la distinción prorrogada. Los miembros podían formar expectativas acerca de la continuidad de solicitudes compatibles con el espacio heredado. Las demás instituciones podían contar a AFRINIC entre los registros que habían completado su paso. Reducir incertidumbre regional es una función real de coordinación, aunque no sea lo mismo que modificar el servicio mundial.

También concluyó una responsabilidad local dentro de una cadena compartida. El procedimiento global dependía de que cada región examinara una redacción sustancialmente equivalente. Al terminar su paso, AFRINIC eliminó una fuente regional de demora o ambigüedad. La organización no necesitaba esperar pasivamente a la ceremonia final para preparar sus operaciones; podía alinear recursos, identificar dependencias y estar lista para la entrada en vigor común.

Ese es el sentido más fuerte y defendible del registro del 26 de mayo. «Implementada» puede querer decir que AFRINIC completó la adopción regional, incorporó el texto a su marco de servicio y alcanzó preparación local condicionada a la cadena global. Muchas infraestructuras coordinadas funcionan precisamente así: cada participante termina tareas bajo su control antes de que el último participante active el estado común.

Pero el carácter real del acto no autoriza a engrosarlo. No consta que el 26 de mayo se editara una base de datos, se desplegara una versión de software, se cambiara un formulario, se enviara una instrucción al personal o se ejecutara una prueba. Tampoco consta una asignación distinta desde IANA, una petición de miembro resuelta bajo una regla nueva ni una modificación de encaminamiento. La frontera no es semántica; es probatoria.

Lo que el registro no permite afirmar

La primera ampliación indebida sería decir que AFRINIC promulgó o ratificó la política mundial. El proceso descrito por ICANN distribuía las funciones entre los cinco RIR, el NRO-EC, el ASO-AC, el Consejo de ICANN y la implementación de IANA. AFRINIC controlaba su propio paso, no los posteriores. Haber terminado antes no le otorgó capacidad de sustituirlos.

La segunda sería convertir el estado de una página en constancia de producción. Una ficha puede actualizarse porque el Consejo aprobó una propuesta, porque el texto se publicó, porque los procedimientos estaban listos o porque un cambio ya entró en vigor. Mientras no se identifique el criterio empleado, la palabra no selecciona una de esas posibilidades. Afirmar un despliegue concreto rellenaría con imaginación el espacio que dejan los recibos ausentes.

La tercera sería atribuir un resultado a operadores africanos. La lógica económica de la prórroga es plausible y está documentada: el inventario solo de 32 bits podía resultar inútil para solicitantes cuya infraestructura no estaba preparada, de modo que la escasez relevante era la del inventario compatible. Sin embargo, pasar de ese riesgo general a la experiencia de una red particular exige datos de solicitudes, compatibilidad y resultados que no figuran en el expediente público utilizado aquí.

La cuarta sería tratar la aceptación regional como una delegación de poder político. El consenso de AFRINIC-11 fue una entrada técnica del procedimiento, no un plebiscito, un mandato de todos los miembros ni una ley. No se conoce aquí un recuento que permita llamarlo unánime o representativo de todos los operadores. Su importancia consiste en informar y permitir una función limitada de coordinación, no en crear un soberano privado.

La quinta sería inferir mala conducta de la discrepancia entre el 24 y el 25 de mayo o de la anticipación del estado implementado. Los documentos no sostienen engaño, incompetencia ni ilegalidad. Una diferencia de un día puede tener explicaciones administrativas ordinarias, y una implementación regional temprana puede ser plenamente racional. La disciplina consiste en conservar la discrepancia y pedir el instrumento, no en adjudicar una intención desconocida.

La defensa más fuerte de AFRINIC

Un registro regional no administra una cadena mundial esperando inmóvil a que todos los demás terminen. Si una regla global va a cambiar, el registro debe entender su inventario, preparar a su personal, comunicar el tratamiento previsto de las solicitudes y comprobar que sus procedimientos serán compatibles con la fecha común. Retrasar todo trabajo hasta la ratificación de ICANN podría producir el peor resultado: una política formalmente vigente, pero un servicio regional todavía incapaz de aplicarla.

Desde esta perspectiva, el 26 de mayo puede representar una buena práctica de preparación. AFRINIC ya había obtenido el juicio técnico regional y la aprobación de su Consejo. Todas las regiones habían aceptado la propuesta. El resultado global era previsible aunque los traslados formales siguieran pendientes. Marcar la propuesta como implementada podía indicar que la organización había completado cuanto estaba bajo su control y no pretendía reabrir la decisión regional.

La publicación también daba una referencia a los miembros. La enmienda protegía durante un año adicional la separación de inventario relevante para compatibilidad. Un anuncio regional temprano podía evitar que solicitantes y equipos internos planificaran bajo fechas distintas. En un sistema distribuido, la preparación adelantada reduce riesgo de coordinación y permite detectar incompatibilidades antes del cambio común.

Nada en la cronología demuestra que AFRINIC intentara arrogarse el papel de ICANN o IANA. El propio hecho de que la propuesta continuara por los canales de NRO y ASO es compatible con una organización que distinguía su paso regional del paso global, aunque la página pública no explicara esa distinción con suficiente detalle. La defensa merece crédito completo: el rótulo pudo ser legítimo en sentido local, oportuno en sentido operativo y útil para la coordinación.

Precisamente por eso, exigir precisión no es una acusación contra AFRINIC. Una etiqueta por capas habría protegido su actuación frente a interpretaciones excesivas. «Implementación regional completada; vigencia global pendiente» habría dicho más con menos ambigüedad. Un enlace a cambios de procedimiento o a una lista de preparación habría demostrado que el registro no usaba la palabra como sustituto de trabajo real.

La objeción más fuerte

La palabra elegida puede colapsar instituciones que cumplen funciones distintas. Para un lector que no conozca la arquitectura, «Implemented — 26 May 2010» sugiere que la política está en vigor y que el servicio afectado ya cambió. Sin una etiqueta de capa, el lector no ve que el traslado NRO-EC–ASO-AC seguía pendiente ni que ICANN ratificó casi cuatro meses después.

Esa ambigüedad tiene consecuencias de atribución. Si el 26 de mayo se toma como fecha global, desaparecen de la explicación los actos de julio, la decisión de septiembre y el trabajo posterior de IANA. Una futura auditoría puede asignar a AFRINIC una decisión que no controlaba o interpretar una transacción según una norma que todavía no había completado el proceso común. El historial deja de ser una secuencia verificable y se vuelve un conjunto de palabras institucionales incompatibles.

También puede ocultar la diferencia entre preparación y resultado. Un registro que publica una norma quizá no haya probado sus formularios, conciliado su inventario ni atendido una solicitud real. Si «implementación» se acepta sin recibos, la organización obtiene crédito por efectos que no se han observado y el operador asume el coste de descubrir fallos. En un entorno de recursos únicos, esa opacidad puede traducirse en demoras, dependencia de decisiones administrativas y escasez efectiva de la clase compatible.

La objeción no necesita afirmar que la etiqueta fuera falsa. Basta señalar que su contenido operacional permanece indeterminado. Una clasificación verdadera en una capa puede inducir una inferencia falsa en otra. La solución no es prohibir el verbo ni reescribir el pasado, sino exigir que el acto indique el objeto cambiado, el responsable, el alcance, la fecha efectiva y la evidencia con la que puede comprobarse.

El recibo de implementación que falta

No se ha recuperado un parte interno de cambio para el 26 de mayo, una lista de despliegue, una diferencia de configuración, una circular al personal, un resultado de prueba ni un plan de reversión. Tampoco aparece una traza de asignación entre IANA y AFRINIC causada por la enmienda, ni una solicitud de miembro procesada de modo distinto antes y después de esa fecha. El registro público no dice si la fecha era la de anuncio, publicación, entrada en vigor, preparación interna, despliegue o una combinación.

Esos vacíos no autorizan a decir que el trabajo no existió. Los archivos internos pueden no haber sido públicos o pueden haberse perdido. La afirmación correcta es más limitada: no se dispone de evidencia directa para identificar el cambio productivo. Esa formulación conserva la posibilidad histórica sin convertirla en hecho.

Un recibo completo habría empezado por el instrumento de decisión: versión exacta de la propuesta, órgano que aprobó cada capa y fecha separada para aprobación, publicación y efecto. Después habría identificado el propietario operacional, el procedimiento afectado y la dependencia superior. Si el cambio alcanzaba un formulario, una tabla de inventario, una interfaz o una instrucción de revisión, la diferencia correspondiente habría permitido ver qué se modificó.

La siguiente parte habría mostrado pruebas. Casos para solicitudes que todavía requerían compatibilidad de 16 bits; casos para números utilizables como 32 bits; resultados aprobados y fallidos; condiciones excepcionales; inventario disponible por clase sin revelar titulares; y una regla de reversión si la cadena global no se completaba. La evidencia debía demostrar tanto que la organización estaba lista como que su preparación no anticipaba indebidamente un acto mundial todavía pendiente.

Por último, una constancia transaccional anonimizada habría unido el texto con el servicio. Bastaba un ejemplo anterior y otro posterior, con tiempos de atención, decisión aplicada y conciliación con el estado de IANA. Una auditoría independiente podía entonces verificar que el estado anunciado correspondía a una realidad observable y no solo a una actualización editorial.

Primacía del código en ejecución

La política se justificaba por una fricción entre la expansión formal del espacio de ASN y la capacidad real de utilizarlo. Esa fricción muestra por qué el código en ejecución debe tener primacía sobre la terminología institucional. Una asignación numéricamente válida puede ser operacionalmente inútil si equipos, software o procesos no la aceptan. El registro contable debe mirar esa realidad, no imponerle una fecha por declaración.

La primacía operativa no significa que cada operador tenga veto indefinido. Significa que las decisiones de coordinación deben basarse en compatibilidad comprobable, anunciar supuestos y exponer costes. La prórroga de un año reconocía que el calendario previo había sobreestimado la preparación. Su valor radicaba en ajustar la administración a la infraestructura existente, no en afirmar poder sobre ella.

Un indicador agregado de inventario habría sido insuficiente. Lo relevante era cuántos recursos eran utilizables bajo las restricciones presentes y cuántas solicitudes dependían de la clase heredada. La escasez económica aparecía cuando el conjunto disponible en teoría no coincidía con el conjunto consumible. Sin datos por clase, una institución podía describir abundancia mientras los operadores sufrían espera o se veían obligados a acelerar sustituciones costosas.

La implementación tenía, por ello, dos pruebas complementarias. La primera era administrativa: AFRINIC debía poder mantener la distinción durante la prórroga y conciliarla con lo recibido de IANA. La segunda era operacional: las redes debían poder usar los números asignados sin fallos atribuibles a la transición. La página del 26 de mayo prueba la primera solo en el nivel de intención y estado público; no entrega datos suficientes para verificar los procedimientos, y no prueba la segunda.

Cuando se invierte ese orden, la etiqueta se convierte en una política espejo: la institución mira su propio documento y confunde lo escrito con lo ocurrido. Una coordinación legítima hace lo contrario. Observa el sistema, registra con exactitud, interviene solo donde la unicidad y la interoperabilidad lo requieren, y deja que la evidencia de funcionamiento determine si la medida cumplió su finalidad.

El límite de autoridad ya estaba dentro del caso

AFRINIC es un contable privado y coordinador de registros únicos. Puede mantener datos, evitar duplicidades, administrar procedimientos de servicio limitados y coordinar coherencia con otras entidades. Esas tareas importan mucho para Internet, pero su importancia técnica no las convierte en soberanía. AFRINIC no legisla para África, no regula como un Estado, no ejerce poder policial o fiscal, no procesa, juzga, castiga, confisca ni se convierte en propietaria de redes o recursos numéricos.

La diferencia entre 26 de mayo y 21 de septiembre ilustra ese límite con precisión. AFRINIC podía terminar su adopción, preparar su servicio y publicar su estado. No podía completar por declaración los pasos del NRO-EC, ASO-AC, ICANN o IANA. El diseño distribuido no era un obstáculo administrativo que pudiera ignorarse; era la prueba de que cada actor tenía una función acotada.

El consenso regional tampoco suministró un principal soberano. Fue información técnica organizada para una decisión de coordinación. Que una propuesta atravesara todas las regiones mostraba compatibilidad procedimental y amplia aceptación dentro de esos canales; no convertía a sus participantes en representantes legales de todos los usuarios ni concedía poder coercitivo sobre operadores ausentes.

El estándar correcto es funcional. Para cada acto debe preguntarse qué problema de unicidad, exactitud, interoperabilidad o continuidad resolvía; qué instrumento autorizaba la función; qué cambio produjo; y qué reparación tenía la parte afectada si el registro se equivocaba. Cuanto más se aleja una medida de esas funciones mínimas, mayor debe ser la carga de justificarla. Ningún prestigio institucional reemplaza el instrumento.

Una conclusión acotada, no una absolución ni una condena

El 26 de mayo de 2010 merece crédito como fecha de un acto regional real. AFRINIC completó su propio ciclo, publicó la enmienda y señaló que estaba preparada para administrarla en su ámbito. En una cadena compleja, ese cierre local podía reducir demora, alinear al personal y despejar una condición previa para el avance mundial. Negarlo sería confundir la falta de un recibo técnico público con la inexistencia de toda actuación.

La misma fecha no merece crédito como ratificación global ni como prueba de un cambio productivo. La exposición de AFRINIC-12 mostró que el traslado formal a la ASO seguía pendiente; los actos de julio y septiembre confirmaron que la cadena continuó. Ningún documento disponible conecta el 26 de mayo con una edición de sistema, una asignación de IANA, una solicitud de miembro o un resultado de operador.

La resolución no exige decidir si AFRINIC usó bien o mal una palabra hace dieciséis años. Exige mejorar el tipo de constancia que acompaña palabras de ese peso. La implementación debe dividirse en capas: gobernanza regional completa; procedimiento regional preparado; política global ratificada; proceso superior modificado; transacción observada; resultado operativo verificado. Cada capa debe tener fecha, propietario, dependencia y recibo.

Entendida así, la función del registro queda a la vez reconocida y limitada. AFRINIC puede coordinar y llevar la contabilidad necesaria para que números únicos sigan siendo utilizables. No puede convertir preparación en realidad global, consenso en mandato ni una página de estado en prueba de funcionamiento. Su mejor defensa no es pedir deferencia a la institución, sino mostrar el cambio que hizo y permitir que cualquiera lo compruebe.