La raíz no gobierna la ruta: AFRINIC, prueba de control y el límite del registro

Resumen

AFPUB-2026-ASN-001-DRAFT02 propone que todo AS-SET nuevo creado en AFRINIC tenga un nombre jerárquico arraigado en un ASN y que el primer hijo solo pueda nacer tras autenticarse contra los datos de autorización de ese ASN. La regla protege una función registral concreta: que el nombre nuevo exprese una cadena comprobable de control. No valida los miembros del conjunto, no modifica RPKI, no determina qué filtros debe instalar una red y no convierte a AFRINIC en autoridad sobre el encaminamiento.
El borrador conserva los AS-SET planos existentes y permite que sigan editándose. También exige excepciones caso por caso, con la restauración de un nombre plano borrado por error como ejemplo. Esa salida es el punto débil: la vía ordinaria se resuelve con un predicado técnico, mientras que la excepción carece de decisor identificado, prueba publicada, apelación y auditoría. Ni consenso, ni Junta, ni contacto de base de datos, ni RSA pueden fabricar soberanía para suplir esa ausencia.

Un nombre puede parecer un detalle hasta que una herramienta lo convierte en política operativa. Un AS-SET se consulta, se expande y puede terminar alimentando filtros de encaminamiento. Si varias bases autónomas contienen la misma etiqueta plana, la respuesta que recibe un operador puede depender de la fuente, del orden de consulta, de la combinación de resultados, de la caché y del tratamiento que haga la herramienta de un conjunto vacío. La cadena causal no nace en una teoría de gobierno. Nace en una pregunta de registro: ¿quién tenía control para crear ese nombre?

AFPUB-2026-ASN-001-DRAFT02 intenta responder solo esa pregunta. No regula toda la exactitud de los IRR. No certifica el contenido de los AS-SET. No determina si una ruta es correcta, si una relación comercial es aceptable o si un operador merece participar. Su intervención sucede en el momento de alta de un objeto nuevo en la base de AFRINIC. El primer componente del nombre tendría que ser un ASN bajo control del creador autenticado; el segundo, un nombre de AS-SET que comience por AS-; los componentes posteriores podrían ser ASN u otros nombres de AS-SET.

La estrechez es su virtud. Un registro regional existe para mantener referencias útiles a las redes que operan: unicidad, exactitud, prueba de control, contacto, seguridad registral y continuidad. Puede registrar. Puede coordinar. Puede proteger la unicidad. No puede gobernar las redes cuya realidad anota. El hecho de que AFRINIC pueda aceptar o rechazar la creación de un objeto dentro de su propia base no le da propiedad sobre el ASN, el conjunto, las rutas, los clientes ni las decisiones de interconexión. La base es una capa descriptiva y coordinadora. No es un título soberano.

El registro es una prueba, no una fuente de realidad

La distinción doctrinal es sencilla y no admite relativización. Un registro describe realidad; no la crea. La realidad de una red reside en su operación, sus relaciones, sus controles, sus contratos, sus rutas y las decisiones locales de quienes intercambian tráfico. El registro puede reducir fricción al publicar una representación verificable de parte de esa realidad. Cuanto más exacta sea esa representación, más útil será. Si el registro se aparta de la realidad, la realidad no desaparece: el registro se vuelve falso.

De ahí que una regla de autenticación pueda ser correcta sin convertirse en una licencia. AFRINIC puede exigir prueba de control para publicar un nombre nuevo cuya raíz afirma una relación con un ASN. No está decidiendo si el creador es moralmente digno, si su política de encaminamiento es buena o si su modelo comercial debe existir. Está comprobando que una afirmación registral concreta no sea acuñada por quien no controla la raíz que invoca. Esa prueba protege la exactitud del libro; no eleva al tenedor del libro por encima de aquello que registra.

También por eso el rechazo de una alta defectuosa no equivale a castigo. Si una solicitud no satisface la forma jerárquica o no supera la autenticación del ASN raíz, el registro puede negarse a publicar esa afirmación. La consecuencia debe permanecer confinada al objeto solicitado. No autoriza a AFRINIC a revocar recursos, juzgar el comportamiento del operador, invalidar rutas, intervenir en acuerdos de interconexión ni utilizar WHOIS, RDAP, RPKI u otros servicios como palanca disciplinaria.

Una Junta puede administrar una corporación. Un proceso de discusión puede elaborar una regla de servicio. Un consenso puede mostrar acuerdo entre quienes participaron. Un RSA puede ordenar una relación contractual. Ninguno de esos instrumentos crea soberanía sobre redes que funcionan de manera independiente. Una sala no es una legislatura. Una lista de correo no es un pueblo. Un contacto de base de datos no es un poder corporativo. La cooperación que hace útil al registro no transforma al registro en gobierno.

La regla exacta: raíz ASN y autorización local

La propuesta fue presentada por James Bensley, de Inter.link GmbH, como una nueva sección 7.8 del manual de políticas de AFRINIC. DRAFT01 fue presentado el 15 de mayo de 2026. DRAFT02 llegó el 8 de junio, 24 días después, tras comentarios en la lista de correo, e incorporó la disposición explícita de excepción y restauración. La evaluación del personal está fechada el 15 de junio, siete días después. La página de la propuesta dice que DRAFT02 fue presentado en AF37 el 24 de junio, nueve días más tarde.

El patrón mínimo sería AS<ASN-controlado>:AS-<nombre-del-conjunto>. El primer componente tiene que ser AS seguido por un ASN controlado por el creador autenticado. El segundo tiene que ser un nombre de AS-SET que comience por AS-. Los dos puntos separan los niveles. Los componentes posteriores pueden ser ASN o nombres de AS-SET.

La comprobación del primer nivel debe hacerse contra los datos de autenticación asociados al objeto ASN que ocupa la raíz. No basta con que el solicitante posea cualquier credencial de mantenedor. Tampoco basta con elegir una etiqueta que sugiera relación con una red conocida. La afirmación incorporada al nombre es precisa —«este hijo nace bajo este ASN»— y la prueba debe corresponder a esa afirmación.

En niveles posteriores, RFC 2622 asigna la autorización de un hijo al mantenedor del conjunto padre inmediato. La cadena no vuelve necesariamente al ASN para cada descendiente. El mantenedor del ASN controla la creación del primer hijo; el mantenedor de ese AS-SET controla su hijo inmediato; y así sucesivamente. Cada transición queda ligada a un punto local de control. Esta arquitectura limita la función común a lo que puede verificarse: forma del nombre, padre pertinente y credencial correspondiente.

La jerarquía, por tanto, no transmite una reputación general desde la raíz. Demuestra quién pudo abrir cada rama dentro de la cadena registrada. Un AS-SET correctamente arraigado puede contener miembros equivocados. Puede quedar obsoleto. Puede ser consultado desde una fuente inadecuada. Puede alimentar un filtro mal diseñado. La prueba de control en el alta no es una garantía eterna sobre el contenido ni una aprobación institucional de las decisiones del operador.

La restricción se aplica expresamente a AS-SET. No se extiende a route-set ni a otros conjuntos RPSL. Tampoco modifica ROA o RPKI. La propia evaluación del personal clasificó RPKI entre las áreas que no requerirían cambios. Los IRR expresan contexto de política de encaminamiento; RPKI ofrece autorización criptográfica de origen. Confundirlos inflaría una regla de nombres hasta convertirla en una promesa que no puede cumplir.

Por qué una etiqueta plana deja abierta la autoridad

Las instrucciones publicadas de MyAFRINIC describen la creación de nombres planos que empiezan por AS- y una operación autorizada mediante credenciales de mantenedor. Esa operación prueba acceso a un mantenedor. El nombre, sin embargo, no contiene necesariamente una relación comprobable con el ASN de la organización que parece representar.

James Bensley sostiene en la propuesta que los nombres AS-SET no son únicos entre los IRR operados por los cinco registros regionales y que los resolutores que agregan fuentes pueden devolver una expansión equivocada o vacía. La mecánica es plausible. MANRS documentó una colisión de AS-AMAZON entre RADB y RIPE y mostró que un mantenedor no relacionado podía crear una etiqueta plana, mientras que la creación de un nombre jerárquico arraigado en un ASN fallaba sin la autorización pertinente.

Ese material prueba la demostración descrita y el ejemplo atribuido. No prueba intención maliciosa. No ofrece una tasa de incidentes. No establece cuántas colisiones existen en AFRINIC, cuántas han causado un filtro erróneo ni qué pérdidas produjeron. La propuesta tampoco aporta un inventario, un denominador o una serie temporal. La evidencia respalda una clase de riesgo, no su frecuencia.

La jerarquía actúa antes de que el consumidor resuelva la ambigüedad. En lugar de confiar exclusivamente en que cada red conserve la procedencia correcta y configure bien sus fuentes, el registro impide una clase de alta no autorizada dentro de su propia base. La procedencia sigue siendo necesaria. La autenticación de raíz y la calificación por fuente resuelven fallos diferentes y pueden coexistir.

La ganancia exacta es esta: para un nombre nuevo en AFRINIC, la relación entre la raíz ASN y el creador pasa de insinuada a comprobable. La ganancia no es esta: que el nombre sea globalmente único, que todos sus miembros sean correctos o que todos los operadores deban confiar en él. La primera afirmación cabe en la función registral. Las demás invadirían superficies que pertenecen a bases autónomas y decisiones locales.

Sintaxis, texto institucional y código en ejecución

RFC 2622, publicado en junio de 1999, define los nombres jerárquicos separados por dos puntos y el modelo según el cual el mantenedor del padre autoriza al hijo. También deja los procesos de registro fuera de su alcance. El RFC proporciona gramática y semántica. No obliga por sí mismo a AFRINIC a rechazar nombres planos nuevos, no migra objetos antiguos y no diseña excepciones.

DRAFT02 es otro tipo de instrumento. El autor propone el cambio. El proceso de AFRINIC puede discutirlo y producir un acto institucional aplicable a la forma en que AFRINIC presta su servicio registral. La evaluación del personal puede describir viabilidad, sistemas afectados, riesgos y calendario. Esos actos solo prueban lo que cada documento dice que su autor o la institución hicieron. No prueban una obligación desplegada, no convierten el texto en código y no crean autoridad sobre redes externas.

La tercera capa es la que decide si la regla existe en la práctica: WHOIS, los formularios de MyAFRINIC y las interfaces automatizadas deben imponer la misma validación. Una pantalla que rechaza una etiqueta plana no cierra la brecha si otra entrada la acepta. Una política que exige autenticación de raíz no protege nada si el servidor verifica una credencial distinta. Un texto que preserva el legado no sirve si una edición corriente provoca un renombrado accidental.

La prioridad corresponde al código en ejecución porque es ahí donde una afirmación se acepta o se rechaza. Un documento no crea realidad operativa mediante publicación. Una votación no convierte una validación ausente en una validación efectiva. La adopción institucional puede orientar trabajo; solo una implementación uniforme puede cambiar el comportamiento del registro. Incluso entonces, el efecto queda limitado a la compatibilidad y a los objetos de AFRINIC: no autoriza a la institución a gobernar la realidad de otras redes.

Al corte del 9 de agosto de 2026, las fuentes oficiales revisadas no acreditaban ratificación, publicación de texto final en el manual, nota de versión ni prueba de aceptación en producción. La página de DRAFT02 muestra «Last Call» y registra la presentación en AF37 el 24 de junio. El índice oficial de propuestas la clasifica como «Under Discussion». Las dos superficies oficiales se contradicen y ninguna explica la diferencia. No puede afirmarse que la regla estuviera adoptada o implementada.

Esa incertidumbre no rebaja el valor de la regla técnica; limita cualquier afirmación sobre su estado. La distinción importa porque el material oficial solo demuestra actos y afirmaciones atribuibles: que el proponente presentó un texto, que el personal publicó una evaluación, que una página usa una etiqueta y otra usa otra. No demuestra que los operadores hayan recibido una nueva obligación ni que todas las rutas de creación la ejecuten.

La continuidad del legado no convierte la excepción en poder

DRAFT02 prohíbe el renombrado obligatorio de los AS-SET existentes, permite que los nombres planos continúen y evita que una edición ordinaria active una migración. Las tres protecciones preservan una realidad ya desplegada. Un nombre puede estar incorporado en plantillas, generadores, documentación y registros de interconexión fuera del alcance directo de su mantenedor. Cambiarlo de manera retroactiva podría romper dependencias que el registro no ve.

La continuidad operativa no es una gracia concedida por AFRINIC. Es el reconocimiento de que la base debe seguir a las redes y no utilizarlas como rehenes de una nueva convención. La autenticación más estricta para futuras altas puede mejorar la exactitud sin fingir que un texto recién publicado borra dependencias anteriores. El registro registra esa coexistencia; no fabrica la realidad del legado ni adquiere propiedad sobre él por conservarlo.

El coste de esa prudencia es una base de dos épocas. Los objetos planos antiguos no portan en su nombre la nueva prueba de raíz. Los objetos jerárquicos nuevos sí la portarían, si la norma se implementa. La ambigüedad instalada puede persistir indefinidamente porque el borrador no exige migración. No hay datos que permitan medir cuántos objetos planos quedan, cuántos colisionan o cuándo dejarían de ser relevantes.

APNIC muestra que una regla prospectiva puede implementarse preservando objetos anteriores. Su registro oficial marca prop-151 como implementada después de consenso el 2 de marzo y respaldo el 21 de abril de 2023, con publicación el 20 de julio. La comparación demuestra viabilidad de una frontera prospectiva, no el impacto que tendría en AFRINIC.

RIPE NCC ofrece una frontera distinta. Sus registros oficiales muestran que la versión 1.105 desplegó el 13 de diciembre de 2022 la restricción para crear nuevos AS-SET no jerárquicos. Los objetos planos existentes podían actualizarse o borrarse, pero el análisis publicado indicaba que, tras el borrado, no podían recrearse. Allí, la desaparición de un objeto antiguo cierra esa rama del legado.

DRAFT02 obliga a AFRINIC a permitir excepciones caso por caso e ilustra la restauración de un AS-SET plano borrado por error. Esa cláusula reconoce un riesgo verdadero: una eliminación accidental puede romper una referencia utilizada por terceros. Pero el reconocimiento de continuidad no autoriza discreción ilimitada. Preservar una realidad anterior exige probarla; no conceder permiso según preferencia institucional.

La excepción es un problema de prueba, no de gobierno

La vía ordinaria es binaria. El nombre satisface la gramática o no. El solicitante controla la autenticación del ASN raíz o no. Para descendientes, controla el padre inmediato o no. Son predicados que el sistema puede verificar de forma local y uniforme.

La excepción publicada no ofrece esa misma precisión. No identifica quién decide, qué evidencia debe presentar el solicitante, cuánto tiempo puede pasar desde el borrado, cómo se trata un conflicto surgido entretanto, si la restauración conserva mantenedor e historial, quién puede revisar el resultado o qué rastro público queda. La evaluación del personal advirtió que la restauración o recuperación podría convertirse en una brecha operativa y recomendó documentar la razón de cada excepción.

La advertencia del personal prueba que el personal formuló esa advertencia. No prueba que haya existido abuso, ni ofrece una cifra sobre solicitudes. La recomendación de documentar razones tampoco crea por sí sola una regla. Un expediente puede registrar una explicación y seguir ocultando el criterio usado para aceptarla.

Una salida compatible con la función registral tendría que reducir la restauración a hechos comprobables. Podría exigir, como alternativa analítica, evidencia del objeto anterior, continuidad del controlador, error demostrable, ausencia de un conflicto sobrevenido, ventana definida, preservación del historial y marca auditable de la restauración. DRAFT02 no contiene esa prueba cerrada; no debe atribuírsela.

La alternativa documentada por RIPE es más dura: un nombre plano borrado no vuelve. Favorece la convergencia y elimina una puerta administrativa, pero hace que un error sea irreversible y traslada el daño a operadores y consumidores dispersos. Ninguna Junta debe escoger entre esos costes como si poseyera la realidad afectada. El criterio válido es cuál regla mínima protege a la vez unicidad, prueba de control, exactitud y continuidad con la menor discreción posible.

Una excepción no puede convertirse en una capa de castigo o privilegio. AFRINIC no debe preguntar si el solicitante es simpático al proceso, si apoyó una política, si pertenece a una facción o si su modelo de red merece protección. Esos juicios no forman parte de la validez registral. Si dos solicitudes acreditan los mismos hechos, el resultado debe ser el mismo. Si no puede expresarse un criterio de esa clase, el registro está sustituyendo coordinación por poder.

Seis sistemas, dos cambios directos y ninguna corona

La evaluación del personal enumera seis sistemas o áreas. WHOIS y la interfaz IRR de MyAFRINIC requerirían cambios directos. RDAP reflejaría los datos de WHOIS. NetSuite, NMRP y RPKI no requerirían cambios según el personal. Es una evaluación categórica atribuida a AFRINIC, no una auditoría independiente de ingeniería.

MyAFRINIC tenía integración IRR en producción desde abril de 2020 y admitía autenticación de mantenedor mediante contraseña o, opcionalmente, PGP. La propuesta no inventa autenticación donde no existía. Cambia la relación que debe demostrarse al crear el nombre: ya no bastaría una credencial que permita operar un objeto plano; la primera rama tendría que autorizarse contra el ASN que la encabeza.

El personal describió el impacto para los miembros como una curva de aprendizaje menor y posibles cambios de herramientas o automatización. También evaluó que no habría problema jurídico o financiero si bastaban las capacidades existentes. Esas son apreciaciones del personal. No proceden de una encuesta, un presupuesto publicado, una estimación de horas o una medición de ahorro.

El coste puede distribuirse de manera desigual. Una red grande puede actualizar generadores y plantillas con más recursos; una red pequeña puede beneficiarse de una regla clara y, a la vez, soportar proporcionalmente más el ajuste único. La continuidad de objetos existentes reduce una migración inmediata, pero obliga a consumidores y herramientas a convivir con dos convenciones durante un periodo no medido.

La evaluación vinculó capacidad de entrega a MyAFRINIC v2, entonces esperado para el 15 de noviembre de 2026, 98 días después del corte, y dijo que el trabajo de esta política se priorizaría después. La fecha es una expectativa, no un compromiso comprobado. Ni la llegada de MyAFRINIC v2 probaría por sí sola el despliegue de la restricción ni un retraso resolvería el estado normativo.

La implementación debe demostrar consistencia en creación directa, formularios, API, mayúsculas y minúsculas, padres anidados, edición del legado, borrado y restauración. Si el control funciona solo en una interfaz, la política no ha creado una garantía. Si la excepción deja menos rastro que la vía ordinaria, el sistema concentra el riesgo exactamente donde abandona la validación determinista.

Nada en esos cambios convierte a AFRINIC en árbitro del encaminamiento. El servidor puede decidir si publica un objeto en la base que opera. No puede decidir qué rutas son reales para todos, qué fuentes debe consultar otro operador ni qué política debe instalar. La distinción entre administrar una entrada y gobernar una red es el límite que mantiene útil al registro.

APNIC, RIPE NCC, LACNIC y ARIN: comparación sin autoridad prestada

Los demás registros sirven como antecedentes técnicos, no como fuente de poder para AFRINIC. Que APNIC o RIPE NCC hayan desplegado restricciones comparables demuestra que una validación de altas es posible. No concede a AFRINIC soberanía, no convierte la práctica en ley universal y no determina cómo debe gestionar el legado.

APNIC aporta una implementación oficial verificada que conserva los objetos anteriores. RIPE NCC aporta notas de versión, un trabajo concluido y una frontera sin recreación tras borrado. Son los dos comparadores con despliegue directamente verificado en las fuentes revisadas.

LACNIC publica ejemplos técnicos de AS-SET arraigados en ASN. La propuesta de AFRINIC afirma que LACNIC implantó jerarquía con su servidor IRR inicial. Las páginas de LACNIC revisadas no establecen por sí solas que cada vía de creación rechace todos los nombres no jerárquicos. Esa limitación probatoria no demuestra que LACNIC carezca de control. Impide afirmar que el control completo quedó verificado.

ARIN abrió entre el 23 de abril y el 23 de mayo de 2025 una consulta sobre la restricción de nuevos AS-SET no jerárquicos, excluyendo registros existentes y objetos de IRR de terceros. El 30 de abril, su Consejo Asesor rechazó ARIN-prop-342 por considerar el asunto fuera de la política de recursos numéricos y lo redirigió al proceso de sugerencias de servicio. El 30 de mayo, ARIN cerró la consulta añadiendo la función a una lista futura para priorización. No anunció despliegue ni fecha.

Los cuatro antecedentes desmienten que los cinco grandes registros hubieran cerrado ya la misma brecha. También muestran que las instituciones usan rutas distintas —política, trabajo de base de datos o mejora de servicio— para llegar a conductas técnicas parecidas. La etiqueta del proceso no es lo que protege la unicidad. Lo que la protege es una regla mínima que el código aplica y que los operadores pueden comprobar.

AFRINIC tampoco puede extender su control a IRR de terceros. Una raíz autenticada dentro de AFRINIC no elimina un objeto externo, no corrige una fuente que un consumidor prioriza mal y no prueba que otra base aplique la misma gramática. El alcance de la mejora debe expresarse con disciplina: reduciría la futura superficie de altas ambiguas dentro de AFRINIC.

La objeción más fuerte y su límite

La objeción más fuerte dice que la jerarquía no es necesaria ni suficiente para tratar la ambigüedad. Un operador puede conservar el nombre de la fuente, como muestra RADB::AS-GOOGLE en el registro público de PeeringDB para Google, donde figura el ASN 15169. Puede limitar las bases consultadas, fijar precedencia, verificar bilateralmente y mantener RPKI para autorización de origen. La propuesta no corrige miembros erróneos, objetos obsoletos, fuentes inseguras ni filtros defectuosos. Tampoco repara el legado ni alcanza bases de terceros.

La objeción es correcta contra cualquier promesa total. Una referencia calificada por fuente puede evitar parte de la ambigüedad sin exigir un nuevo formato. Y la ausencia de datos de incidencia impide cuantificar el beneficio de la jerarquía.

No derrota, sin embargo, la regla estrecha. La calificación por fuente es un control que cada consumidor debe configurar y conservar. La autenticación de raíz es un control previo que el tenedor del registro puede aplicar al nacimiento de una afirmación nueva. La primera decide de qué base se recibe un objeto. La segunda impide que alguien sin control del ASN acuñe determinada clase de nombre dentro de AFRINIC. Son defensas complementarias.

La evaluación no necesita fingir que DRAFT02 resuelve toda la seguridad del encaminamiento. Basta con afirmar lo que la prueba sostiene: una alta arraigada y autenticada mejora la exactitud de la relación entre nombre y controlador. El registro debe detenerse ahí. Si usa esa mejora para juzgar miembros, imponer filtros, castigar operadores o reclamar autoridad sobre rutas, abandona la función que justificó el control.

Lo comprobado y lo desconocido

Las fuentes oficiales permiten afirmar con alta confianza que DRAFT02 exige nombres nuevos jerárquicos y arraigados en ASN, limita la regla a AS-SET, vincula el primer hijo a la autenticación de la raíz, preserva nombres planos existentes y ordena excepciones caso por caso. Permiten atribuir al personal los cambios previstos en WHOIS y MyAFRINIC, el reflejo en RDAP, la ausencia de cambios esperados en NetSuite, NMRP y RPKI, la evaluación de impacto menor y la advertencia sobre la brecha de restauración.

No permiten resolver si el estado correcto es «Under Discussion» o «Last Call». No acreditan ratificación o implementación al corte. No ofrecen un inventario de nombres planos, una tasa de colisión, una serie de incidentes, un presupuesto, un ahorro medido o una matriz completa de pruebas. No identifican al decisor de excepciones ni un criterio, una apelación o un diseño de auditoría. No establecen una fecha de despliegue para ARIN ni prueban la aplicación integral en LACNIC.

Tampoco se sabe si una restauración conservaría mantenedor, historial de creación y registros de borrado. No se sabe si WHOIS, MyAFRINIC y todas las interfaces automatizadas devolverían el mismo resultado. No se sabe qué configuración concreta de resolutor convierte una colisión en una interrupción o fuga: el resultado depende de fuentes, orden, agregación, caché, expansión y lógica de filtros.

Estas incertidumbres no relativizan el principio. La unicidad, la exactitud, la prueba de control y la continuidad son obligaciones técnicas del registro. Lo desconocido limita la afirmación factual sobre incidencia, estado y ejecución. No concede margen para que AFRINIC sustituya evidencia por autoridad autoproclamada.

Una regla registral válida solo mientras siga siendo estrecha

Si DRAFT02 no se implementa, la vía ordinaria de AFRINIC puede seguir admitiendo nombres planos cuya etiqueta no prueba relación con un ASN. Los operadores conservarán controles descentralizados: fuente explícita, precedencia, verificación bilateral, nombres jerárquicos voluntarios y RPKI para el origen.

Si se implementa tal como está escrito, cada raíz nueva ganará una cadena autenticada dentro de AFRINIC. Los objetos planos existentes continuarán, y la restauración caso por caso dejará una superficie donde la decisión ya no se resuelve únicamente con autenticación. El beneficio será prospectivo; la deuda heredada permanecerá.

Si la restauración se reduce a una prueba cerrada y auditable, podrá preservar un objeto borrado por error sin abrir una licencia general. Si se adopta un límite sin recreación como el documentado por RIPE, la convergencia será más fuerte y el coste de un error mayor. Ambas son alternativas analíticas. DRAFT02 solo contiene la obligación de permitir excepciones caso por caso y el ejemplo de restauración.

La conclusión no depende de la aprobación política de AFRINIC, de su Junta ni de un supuesto soberano colectivo. Depende de la función. Autenticar la raíz de un AS-SET nuevo es una comprobación estrecha que protege el libro común. Puede mejorar la exactitud, la prueba de control, la unicidad nominal y la coordinación de rutas. No crea propiedad sobre el mundo que describe.

La regla conserva su validez mientras el efecto del rechazo se limite al objeto que no satisface la prueba, la implementación sea uniforme y la excepción se ate a hechos verificables. Pierde su justificación en cuanto el registro convierte autenticación en obediencia, inscripción en propiedad, error en castigo, consenso en soberanía o contrato en jurisdicción.

AFRINIC puede registrar. Puede coordinar. Puede proteger la unicidad. No puede decidir la realidad de las redes. El nombre puede estar arraigado en un ASN. La autoridad del registro no lo está sobre el operador.