Resumen

  • ICANN, cualquier RIR o un grupo suficiente de miembros podrían proponer la retirada del reconocimiento. El registro examinado tendría derecho a responder, pero no a vetar su propia salida.
  • La recomendación publicada en septiembre de 2026 exige respaldo de otros registros, una decisión de ICANN y preparación del relevo. Según la actualización de ARIN del 22 de octubre, su adopción seguía pendiente.

Reunir a 2.000 miembros no daría a nadie un botón para destituir a un registro regional de Internet. En la última propuesta de gobernanza, sí podría darles una vía para plantear el caso. La diferencia entre ambas cosas es el centro del texto.

El umbral para que los miembros presenten una propuesta de retirada del reconocimiento es el menor entre el 25 % del total de miembros del RIR afectado y 2.000 miembros. No se exige alcanzar siempre las dos cifras. También podrían iniciar una propuesta cualquier RIR e ICANN. Quien la presente tendría que explicar las razones, identificar las obligaciones supuestamente incumplidas y aportar información suficiente para sostenerlas.

Son reglas de la versión 3 recomendada, publicada el 1 de septiembre de 2026. Todavía no deben presentarse como una nueva vía de recurso ya operativa. Pero permiten descartar una lectura anterior: ICANN no estaría condenada a esperar que los registros quisieran iniciar el expediente por ella.

El registro afectado responde; los demás evalúan

Una vez planteado el caso, el RIR señalado dispondría de un plazo razonable para contestar. Los otros registros harían sus evaluaciones. ICANN tomaría la decisión final, que requeriría el apoyo de al menos dos tercios de los RIR, excluido el afectado.

Ese último detalle cambia por completo la idea de un veto propio. El registro conservaría garantías para defenderse y corregir sus fallos; no tendría un voto con el que impedir por sí solo cualquier retirada del reconocimiento.

El PDF de referencia también obliga a tomarse en serio la rehabilitación. La retirada se contempla para un incumplimiento sustancial que persista después de una oportunidad razonable de remediarlo. Si esa oportunidad no se ha ofrecido, el procedimiento debe pasar por un plan de rehabilitación y volver a examinar el caso una vez concluido su plazo. No basta con contar adhesiones a una queja.

Las razones quedarían a la vista: ICANN publicaría las evaluaciones y la decisión, con las salvaguardas previstas para información confidencial. El proyecto no demuestra que exista hoy una infracción o un expediente contra un RIR concreto. Define cómo se tramitaría uno bajo ese marco.

Entrar exige otro recuento

La admisión de un nuevo RIR se parece a la retirada en que combina análisis de los pares y decisión de ICANN. Sin embargo, no utiliza exactamente el mismo denominador. El candidato presentaría su solicitud a ambos, y el reconocimiento necesitaría el apoyo de dos tercios de los registros que entreguen evaluaciones.

Los evaluadores no son ajenos a las consecuencias. Un nuevo registro puede afectar al territorio de servicio o a los ingresos de uno existente. Por eso se exige revelar intereses pertinentes. ICANN podría excluir del umbral una recomendación negativa procedente de un RIR sustancialmente afectado, pero antes tendría que notificarlo por escrito, explicar su juicio y darle una oportunidad razonable de responder. Esa respuesta debe considerarse de manera justa; la opinión excluida seguiría siendo información para el examen.

La explicación de cambios del ASO destaca estas obligaciones. No son una licencia para desechar toda objeción de quien tenga intereses, ni convierten a ICANN en un decisor sin límites. Obligan a distinguir entre la objeción, sus fundamentos y el peso que puede tener en el recuento.

La continuidad no se resuelve retirando un nombre

Si se aprobara una retirada, habría que publicar un plan de transición con plazos y condiciones. El RIR saliente tendría que facilitar la transferencia de servicios y operaciones a una entidad sucesora o provisional. El documento no dice que todos los registros de recursos se invaliden automáticamente al cambiar la institución responsable.

Para una incapacidad de prestar servicios existe además una vía temporal. El propio RIR podría activarla para sus servicios; también podrían hacerlo ICANN y dos tercios de los otros RIR. En este segundo supuesto se prevé conversar con la institución afectada y su comunidad cuando resulte razonablemente posible. El arreglo no duraría más de 90 días salvo renovación, y el RIR podría recuperar los servicios una vez restablecida y verificada su capacidad.

De ahí que la FAQ del NRO hable del ciclo de vida de los registros: reconocimiento, funcionamiento y posible retirada. Un mecanismo que sostiene servicios durante una emergencia no es una destitución automática a los tres meses.

La propuesta ha avanzado; la adopción es otra etapa

El 22 de octubre, ARIN informó de la explicación de Michael Abejuela: el NRO Executive Council había entregado el documento a ICANN para su consideración. Aún quedaban una última consulta, comentarios públicos, adopción por los consejos de los RIR y de ICANN, y procedimientos de aplicación. «Borrador final» describe una fase del trabajo, no una fecha de entrada en vigor.

La versión 2 de agosto de 2025 ya contenía vías de iniciativa y reglas de relevo. La nueva recomendación cambia umbrales y desarrolla procedimientos. Leer cada versión completa importa más que extraer una frase sobre los límites de ICANN y convertirla en una prohibición de iniciar cualquier caso.

Corrección y actualización, 24 de octubre de 2026: el artículo anterior confundía iniciativa y decisión, atribuía al registro afectado un veto propio y afirmaba que faltaban disposiciones de relevo. También pasó por alto consultas públicas ya documentadas. Corregimos esos puntos e incorporamos la versión 3 y el estado del proceso comunicado el 22 de octubre. La fecha de la versión 2 es el 28 de agosto de 2025; una marca temporal contradictoria de una página no vuelve incierta esa fecha documental.