Resumen

  • La publicación de APNIC del 1 de septiembre deja disponibles el proyecto recomendado v3.4 del NRO NC, el texto con cambios y su explicación.
  • El artículo 7.2 impediría modificar el documento mientras un RIR esté bajo un Temporary Emergency Continuity Arrangement o exista una propuesta de Derecognition pendiente.
  • La razón declarada es evitar cambios apresurados para un caso concreto o requisitos rebajados en un momento difícil; es un proyecto, no prueba de una emergencia real ni de una regla adoptada.

Una de las cláusulas más expresivas del documento v3.4 es también muy breve. El artículo 7.1 establece que cualquier enmienda requeriría acuerdo unánime de ICANN y de los RIR, después de consultar a sus comunidades. El artículo 7.2 añade una condición: el texto no podría enmendarse durante un Temporary Emergency Continuity Arrangement que afecte a un RIR, ni mientras esté pendiente una propuesta de Derecognition.

La nota de APNIC del 1 de septiembre ubica bien el alcance. Es un proyecto recomendado por el Number Council de la NRO, acompañado por una versión comparada y un informe de razones. La publicación no anuncia adopción final, implementación ni la activación de un caso. Tampoco establece que algún RIR esté bajo continuidad de emergencia, enfrente un proceso de Derecognition o intente cambiar el documento.

Pero la justificación sí es clara. El informe explica que la nueva condición busca impedir cambios rápidos para responder a circunstancias específicas, o que se diluyan los requisitos justamente en momentos difíciles. Es una precaución institucional limitada: las partes no deberían reescribir las reglas que encuadran una emergencia o una posible desreconocimiento mientras dependen de ellas.

El artículo 5 delimita el caso. Un Temporary Emergency Continuity Arrangement es una herramienta temporal para prestar servicios de RIR afectados. El RIR afectado podría iniciarlo para todos o parte de sus propios servicios. ICANN y dos tercios de los otros RIR también podrían iniciarlo o renovarlo tras conversar con el RIR y su comunidad cuando sea razonablemente posible. No puede superar 90 días salvo renovación conforme a la misma sección, y ICANN tendría que publicar pronto la razón y el alcance de cada inicio o renovación. Son procedimientos posibles, no una descripción de un hecho ocurrido.

La eficacia pública del bloqueo depende de poder saber cuándo está activo. El proyecto prevé publicaciones puntuales, pero no define un registro único para enlazar un acuerdo o propuesta con el estado del artículo 7.2. Bastaría un recibo sencillo: RIR afectado, tipo de situación, decisión y hora de vigencia, alcance, enlace al aviso, renovación o cierre, responsable y correcciones. No exigiría divulgar asesoramiento jurídico, detalles operativos sensibles ni posiciones negociadoras.

Eso no convertiría el proyecto en norma vigente ni resolvería una crisis. Solo permitiría separar una salvaguarda futura de un bloqueo actual. Esa diferencia evita que una descripción pública del proceso se convierta, sin evidencia, en una afirmación sobre el estado operativo.

Sources