Resumen

  • El borrador de septiembre solicita a IANA un bloque IPv6 para uso espacial y propone una función distributiva para el NRO; sigue siendo un Internet-Draft individual y no avalado, no una política adoptada.
  • El NRO afirma que no formula políticas sobre recursos numéricos. El texto no explica cómo su función propuesta se conecta con los procesos independientes de las cinco comunidades RIR, incluida RIPE.

La pregunta decisiva está en el paso entre funciones

Una petición de espacio de direcciones puede parecer un problema de ingeniería acotado: reservar un bloque, dividirlo en prefijos utilizables y mantener el encaminamiento ordenado. El Internet-Draft de septiembre de 2026 para entornos espaciales va más lejos. Solicita a IANA la asignación de un bloque y dice que la Number Resource Organization (NRO) determinaría cómo estructurar, asignar y distribuir los recursos para los cuerpos celestes y dentro de ellos. En otra frase, el sistema de registros establecería las políticas de asignación.

Esa redacción abre una interfaz de gobernanza, pero no acredita que se haya ejercido autoridad, que exista una asignación o que haya cambiado una política. La primera página indica “Intended status: Standards Track”, mientras que los metadatos de Datatracker muestran “None” tanto para RFC stream como para Intended RFC status. Datatracker lo clasifica como Internet-Draft individual activo, “I-D Exists”, sin posición formal en el proceso de estándares de la IETF. Es trabajo en curso, no una decisión institucional.

El debate no es si conviene coordinar técnicamente un bloque que pudiera abarcar varias regiones. Es cómo esa coordinación se enlaza con la autoridad que define a quién se asignan recursos, con qué requisitos y qué revisión o recurso existe.

Coordinar no es formular política

La descripción oficial del NRO establece un límite: coordina los cinco Registros Regionales de Internet y cumple la función de Address Supporting Organization de ICANN, pero no desarrolla, aprueba ni implementa políticas regionales o globales sobre recursos numéricos. Las comunidades regionales definen sus propias reglas mediante procesos abiertos. La FAQ añade una vía global distinta: con aportes de los RIR, el NRO revisa y formula recomendaciones sobre política global de direcciones IP para que las ratifique la junta de ICANN.

Esa función consultiva no aclara si el borrador busca una regla global o cinco decisiones regionales coordinadas por el NRO. El NRO también distingue esos servicios de registro regionales de la coordinación entre RIR.

El borrador de septiembre incorpora al NRO a la cadena de distribución propuesta y atribuye la formulación de políticas al “sistema de registros”. Aún no hay un procedimiento identificable detrás de esas expresiones. ¿La distribución ejecutaría reglas ya aprobadas por las comunidades RIR? ¿Sería una recomendación para ellas? ¿O se crearía un instrumento común? El texto no lo aclara. Tampoco cabe asumir que el sistema de registros sea una autoridad política unificada.

Un borrador individual de TIPTOP de mayo de 2026 planteaba otra arquitectura: IANA delegaría el espacio a los RIR existentes y cada uno fijaría las reglas por sus cauces habituales. Permite comparar propuestas, pero no demuestra que el texto de septiembre lo haya sustituido ni que se haya adoptado ninguno. La diferencia merece explicación; no demuestra por sí sola un desacuerdo.

RIPE aporta un proceso, no un respaldo

RIPE NCC presta servicios regionales de registro y apoya el proceso abierto de políticas de la comunidad RIPE. La política IPv6 publicada, incluida RIPE-738, es la referencia regional vigente. Un régimen espacial debe explicar qué asuntos corresponden a RIPE, cuáles se coordinan entre RIR y cómo se resuelve un choque entre una regla global de distribución y una decisión regional.

El documento de septiembre no es una propuesta de RIPE. Sin embargo, habla de coordinación entre RIR y del “sistema de registros”, mientras el modelo de RIPE sitúa la política en su comunidad. Las fuentes revisadas no indican que RIPE NCC haya respaldado el texto, presentado una propuesta por la comunidad o aceptado una nueva obligación. Las actas de TIPTOP en IETF 126 prevén una reunión intermedia para definir requisitos técnicos con IANA y representantes de RIR. Una reunión técnica planificada no autoriza la asignación ni la gobernanza de un bloque.

La próxima versión puede aclarar la frontera

La especificación debería identificar el foro que decide elegibilidad y criterios de asignación; precisar si el NRO coordina, recomienda o ejecuta; decir qué RIR conserva los registros; y explicar las decisiones, objeciones, correcciones y apelaciones. También debe contemplar recursos que crucen regiones y políticas regionales distintas.

No son detalles editoriales. Determinan si la asignación técnica puede operarse sin trasladar silenciosamente la autoridad política. Si deciden las comunidades regionales, el texto debe explicar cómo se combinan esas decisiones. Si se propone una regla común, debe decir quién la adopta y cómo interviene cada comunidad. Mientras no se elija un camino, “sistema de registros” no debe sustituir a un responsable identificable.

La evidencia permite una conclusión limitada: el nuevo borrador propone una distribución coordinada por el NRO, pero no documenta la conexión con la política que la sostendría. El proceso de RIPE no ha sido desplazado. La siguiente prueba útil sería una revisión que muestre dónde termina la coordinación, dónde empieza la política y cómo sabrán operadores y solicitantes qué norma se aplica.

Fuentes