Resumen
- El 28 de julio, la NRO comunicó que la ASO AC había completado la versión 3 del RIR Governance Document, entregado formalmente el Recommended Draft al NRO EC y transferido a este órgano la responsabilidad sobre el documento.
- La entrega no fue una aprobación. El NRO EC aún debe revisarlo, coordinar con ICANN y los RIR y conducir la ruta hacia una versión final.
- El texto, la explicación de los cambios desde la versión 2, el documento comparativo, el calendario renovado y cualquier nueva oportunidad de participación quedaron pendientes de publicación posterior.
- El último informe público había dejado abiertas decisiones sobre reconocimiento, auditorías, desreconocimiento, continuidad de emergencia, transición y derechos de titulares. Sin la versión 3, el público no puede saber cómo se resolvieron.
El cambio comprobable ocurrió en la cadena de control
La noticia del 28 de julio puede representarse como una transición de estado.
Antes de la entrega, la ASO Address Council —también NRO Number Council— controlaba la redacción. Después, el NRO Executive Council pasó a ser responsable del documento, de su revisión y de la coordinación con ICANN y los cinco registros regionales. AFRINIC incorporó el titular y el resumen a su portada, confirmando la relevancia del paso para su propia audiencia.
Lo que no cambió de estado públicamente fue el documento. La NRO dijo que publicaría por separado la versión 3, una justificación de las diferencias principales y un redline que mostrara las modificaciones desde la versión 2. También pospuso el nuevo calendario, los detalles del proceso y la información sobre una posible fase adicional de aportaciones.
Así, la custodia tiene fecha; la configuración entregada no tiene todavía una versión pública verificable.
Cuatro estados que no deben mezclarse
El expediente exige separar al menos cuatro momentos: borrador recomendado, revisión ejecutiva, aprobación y adopción.
El 28 de julio sólo se acreditaron los dos primeros. La ASO AC recomendó un texto y el NRO EC comenzó su responsabilidad de revisión. El comunicado no dice que los RIR lo hayan aprobado, que ICANN lo haya adoptado o que alguna obligación nueva esté vigente.
La página del proceso asigna a NRO EC e ICANN la futura determinación de los procedimientos de aprobación y adopción. El plan anual había previsto trabajo sobre el borrador final en julio-agosto, presentaciones regionales en septiembre-octubre y preparación de aprobación en noviembre. Como el propio comunicado promete un calendario actualizado, esas fechas son el plan anterior, no una garantía actual.
Llamar “política vigente” a la versión 3 sería adelantarse a los hechos. Tratar la entrega como mero correo administrativo ocultaría, en cambio, que el control de la próxima decisión ya pasó a otro nivel.
La matriz de asuntos abiertos
El informe de estado publicado en mayo permite construir una matriz de lo que seguía en discusión tras la versión 2.
En reconocimiento, faltaba cerrar el papel de una revisión independiente y el equilibrio de “unanimidad menos uno” cuando varios RIR tuvieran conflictos o no pudieran decidir. En desreconocimiento, la versión 2 permitía activar una propuesta por cualquier RIR, por el 25% de los miembros del registro afectado o 2.000 miembros —la cifra menor—, o por ICANN.
El NRO NC mantuvo ese umbral de desreconocimiento, pero dejó en discusión si una auditoría ad hoc debía poder activarse con menos apoyo. También valoraba periodos de espera para impedir que una misma disputa encadenara auditorías.
La continuidad de emergencia concentraba otra decisión crítica. La versión 2 exigía unanimidad de todos los demás RIR e ICANN. El informe reconoció que el umbral podía resultar demasiado alto durante una urgencia y que las extensiones de 90 días necesitaban criterios y supervisión más claros.
En transición, los redactores prometieron añadir requisitos para mantener el servicio y proteger los derechos de los titulares de recursos. En auditoría, se comprometieron a aclarar qué debía hacer un RIR tras publicarse el informe. En rehabilitación, iban a integrar expresamente ese paso en la secuencia previa al desreconocimiento.
Cada fila contiene poder: iniciador, umbral, decisor, plazo, remedio y recurso. El redline de la versión 3 debe mostrar cómo cambió cada uno. Mientras no aparezca, no existe base para afirmar que una salvaguarda fue aceptada o descartada.
De la participación al mandato hay un salto
El proceso tuvo consultas reales. Hubo cuestionario de principios, consulta del primer borrador, segunda consulta de la versión 2, comentarios públicos de ICANN, sesiones en reuniones regionales y un taller de revisión. Esa historia sirve para conocer qué argumentos llegaron a los redactores.
No convierte automáticamente a todos los participantes en quienes autorizan la decisión final.
La Note 73 de Heng Lu separa stakeholder y principal. El stakeholder está afectado; el principal concede poder vinculante. La participación puede aportar conocimiento y objeciones, pero no se transforma por sí sola en soberanía sobre operadores que no autorizaron al foro.
La prueba aplicable no es cuántas veces aparece la palabra “community”. Es quién puede ordenar una auditoría, quién declara fallido a un RIR, quién activa un operador de emergencia, quién decide el sucesor y qué capacidad tienen los miembros para consentir, impugnar o salir.
Sin el texto, “consenso”, “stewardship”, “estabilidad” y “representación” sólo prueban lo que las instituciones dicen de sí mismas.
La salida determina si hay rendición de cuentas
La crisis de AFRINIC hizo urgente una norma de fallo institucional. La Note 17 de Heng Lu no rechaza ese objetivo: exige que una desreconocida o nueva acreditación decisiva nazca de los miembros y del proceso bottom-up, no de una jerarquía NRO-ICANN.
La Note 25 lleva el examen a la implementación. Un marco puede presentarse como coordinación y, sin embargo, convertir el acceso en permiso, bloquear nuevos participantes y hacer que el incumbente resulte imposible de sustituir. El lenguaje de estabilidad no corrige esa arquitectura.
La Note 6 introduce el contrafactual útil: si el registro falla, ¿puede la red trasladar su relación verificada de IP o ASN a otro proveedor institucional sin perder continuidad? Si no puede, la disciplina depende de que el mismo gatekeeper acepte corregirse.
La versión 3 quizá cambie esos elementos o quizá no. Atribuirle ahora una respuesta favorable o adversa sería inventar hechos. La crítica rigurosa es exigir el documento antes de que los órganos ejecutivos conviertan su propia descripción en sustituto del análisis.
El hecho de que AFRINIC repita el anuncio tampoco valida a su purported Board, al Receiver, a sus apoyos ni una política de lock-in. Una pieza global en revisión no resuelve la autoridad local de quienes pretenden hablar por el registro.
El registro que debe acompañar la siguiente etapa
La NRO EC puede cerrar el desfase con un paquete pequeño y reproducible.
Primero, debe publicar el mismo archivo recibido de la ASO AC con fecha y hash. Segundo, debe adjuntar la justificación y el redline frente a la versión 2. Tercero, debe explicar si durante su revisión puede modificar el texto y, si lo hace, publicar un nuevo comparativo.
El calendario debería identificar el inicio y fin de revisión, las presentaciones, el orden de las decisiones de los RIR y de ICANN, el significado exacto de “aprobación”, la forma de registrar el disenso y si habrá otra ventana de comentarios antes de adoptar.
Una tabla por tema resolvería la trazabilidad: regla anterior, problema recibido, decisión de versión 3, órgano responsable, razón y procedimiento de implementación aún pendiente. Así se podría medir poder en vez de aceptar adjetivos institucionales.
Hay contrapesos que deben constar. La NRO anunció la entrega en público, prometió las piezas faltantes y ya había publicado un redline para la versión 2. El retraso puede responder a la secuencia programada; el expediente no acredita ocultación intencional.
Pero la secuencia produce un hecho actual: la responsabilidad avanzó antes que la inspección. Para miembros de AFRINIC y operadores, ésa es una alerta de control, no una conclusión sobre cláusulas que todavía no pueden leer.
Fuentes
- Anuncio de la NRO sobre la entrega de la versión 3
- Portada de AFRINIC con la noticia
- Índice ICP-2 de la NRO
- Proceso y cronograma de revisión
- RIR Governance Document versión 2
- Diferencias y justificación de la versión 2
- Anuncio del informe de mayo de 2026
- Informe de estado de la versión 2
- Preguntas frecuentes de la NRO
- Revisión de ICP-2 en la ASO
- Plan de trabajo 2026 de la ASO AC
- Criterios ICP-2 aceptados por ICANN en 2001
- NRS sobre la NRO y la gobernanza RIR
- Heng Lu Note 73: el espejismo multistakeholder
- Heng Lu Note 25: poder de implementación y riesgo estructural
- Heng Lu Note 17: normas de fallo y poder bottom-up
- Heng Lu Note 6: portabilidad de recursos numéricos
- LARUS sobre ICP-2 y riesgo operativo
- BTW, lectura adicional: la opción de salida que ICP-2 olvidó


