Resumen

  • El Consejo de ICANN autorizó el 6 de septiembre un contrato de desarrollo de sistemas y soporte para la ronda 2026. La resolución, publicada el día 9, menciona funcionalidad, respuesta a incidentes, estabilidad y procesos críticos, pero oculta proveedor, importe y parte sustancial de la justificación.
  • Una autorización del 3 de mayo había definido seis meses de guardia reforzada, desde la apertura de solicitudes hasta la confirmación de cadenas entonces prevista para el 30 de octubre, con reducción posterior al horario laboral normal.
  • El expediente público no demuestra que ambas decisiones correspondan al mismo proveedor, contrato o alcance. Sí conserva un límite temporal previo que merece un resultado verificable.
  • ICANN puede publicar una prueba de cierre sin datos sensibles: estado de cada función, cobertura normal, responsable interno, evidencia revisada, excepciones pendientes y próxima fecha de decisión.

Una nueva autorización junto a una promesa antigua

Las resoluciones del 6 de septiembre facultan al presidente y director ejecutivo de ICANN, o a sus delegados, para contratar y desembolsar fondos por desarrollo de sistemas y soporte para el Programa de Nuevos gTLD: Ronda 2026. La parte pública enumera cuatro objetivos: desarrollar funcionalidad, responder a tiempo ante incidentes, conservar la estabilidad y sostener procesos empresariales críticos. El impacto fiscal, dice, ya está previsto en el presupuesto FY27 y en presupuestos futuros.

El documento no muestra el catálogo de servicios, horarios, matriz de severidad, duración, cuantía o proveedor. Incluso parte de la explicación operativa está tachada como información confidencial de negociación. La decisión se tramita como función administrativa de la organización sin consulta pública.

La confidencialidad comercial no convierte el contrato en un problema. Tampoco sería responsable revelar vulnerabilidades o instrucciones de intervención. El ángulo relevante aparece al comparar septiembre con las resoluciones del 3 de mayo.

En mayo, ICANN explicó una extensión contractual para un modelo mejorado de soporte de guardia. Lo presentó como respuesta a seis meses de demanda y complejidad elevadas: desde la apertura de la ventana el 30 de abril hasta la confirmación de cadenas, por entonces prevista el 30 de octubre. La cobertura fuera del horario laboral debía atender incidentes con rapidez. Al final del periodo, la expectativa era reducir el equipo y prestar soporte en horario normal.

Ese texto trazó una transición observable. No prometió que todos los sistemas apagarían la guardia a una hora exacta, pero sí distinguió un régimen extraordinario de un estado ordinario esperado. La autorización de septiembre vuelve decisiva una pregunta que no depende del precio: ¿qué evidencia permitirá concluir que una función puede regresar al nivel habitual, y qué autoridad aprobará una excepción?

No se debe rellenar la relación entre contratos. La resolución de mayo dice que el proveedor entonces vigente había sido seleccionado mediante una RFP en octubre de 2023 y había entregado sistemas RSP y ASP, además de avanzar en TAMS. La de septiembre no confirma continuidad de proveedor, contrato o alcance. Una prueba de cierre bien diseñada sigue la capacidad y su propietario interno, no una identidad comercial inferida.

La ventana se cerró; el procesamiento apenas cambió de fase

ICANN anunció más de 1.600 solicitudes principales al cierre del 12 de agosto. Más de 1.100 incluían una cadena sustitutoria. Son expedientes, no sesiones, operaciones ni incidentes. Usar ese total como medida de carga sería engañoso. Pero el dato sí muestra que la actividad posterior no es marginal.

El recorrido del solicitante continúa por revisión administrativa, Reveal Day, aportaciones de la comunidad, objeciones, evaluaciones, resolución de contenciones, contratación, incorporación técnica y delegación. Cada fase cambia quién interviene, qué decisión se toma y qué sistema resulta crítico.

El informe de situación previo a ICANN85 ya mostraba esa secuencia. En febrero, la compilación 5 de TAMS y las pruebas de aceptación estaban terminadas; comenzaba la integración de extremo a extremo; las compilaciones 6, 7 y 8 debían completar funciones de evaluación y contratación. En paralelo, el programa organizaba infraestructura, procesos, formación, disponibilidad del personal y de proveedores, finanzas, compras y apoyo jurídico.

Por eso no existe una única luz verde. La recepción de solicitudes puede estar estable mientras una función de evaluación sigue en desarrollo. Un procedimiento puede pasar a manos de un equipo ordinario mientras otro mantiene una guardia temporal. La pregunta no es si «el programa» está listo, sino qué clase de servicio ha cruzado su umbral.

El contenido mínimo de la prueba

Una ficha pública, fechada y vinculada a las resoluciones, bastaría. Para cada clase amplia de servicio debería indicar:

  1. cuál fue la cobertura extraordinaria y cuál es el nivel ordinario previsto;
  2. qué rol de ICANN acepta el servicio y decide reducir, prolongar o rediseñar el soporte;
  3. qué tipo de evidencia se examinó —recuperación probada, previsión de trabajo, defectos abiertos, traspaso de procedimientos o métricas de guardia definidas—;
  4. qué funciones pasaron a operación estable y cuándo;
  5. qué excepciones siguen abiertas, por qué y hasta qué revisión;
  6. cuál será el siguiente punto de decisión pública.

La ficha no necesita presentar una tasa universal de disponibilidad. Las medias suavizan precisamente los periodos que justifican una guardia. Tampoco conviene publicar cantidades de tickets sin distinguir incidentes, consultas, defectos y cambios planificados. La unidad de medición debe preceder al número.

Una prueba de cierre tampoco presupone cancelación. Puede validar el retorno a horario normal, mantener temporalmente una función en cobertura ampliada, confirmar un traspaso con capacidad de refuerzo o reconocer que el nivel base ha cambiado. El valor reside en que la continuación tenga un motivo, un propietario y una fecha de revisión.

Transparencia sin entregar un manual de ataque

La política de divulgación documental parte de la disponibilidad pública y admite reserva cuando exista una razón de peso, incluida la protección de intereses comerciales. Las prácticas de publicación explican que resoluciones, informes preliminares y actas se publican conforme a los Estatutos, con exclusiones justificadas.

Así puede mantenerse privada la identidad del proveedor mientras dure la negociación, junto con el precio, las credenciales, vulnerabilidades, turnos personales y rutas activas de escalamiento. En cambio, una frase como «la función de evaluación sigue bajo cobertura ampliada hasta la revisión fechada» aporta información institucional sin exponer el sistema.

La política de contratación y desembolsos exige autorización del Consejo por encima de 750.000 dólares y reportes periódicos del director financiero sobre desembolsos significativos. Como el importe concreto está oculto, no procede estimarlo. Y aunque la autorización financiera sea impecable, no responde si el soporte temporal ya puede transferirse. Presupuesto y aceptación operativa son controles distintos.

Límites de la evidencia

Ninguna fuente citada prueba interrupciones, incumplimientos de respuesta, brechas, mala prestación, sobrecostes, bloqueo con un proveedor o fracaso del traspaso. El número de solicitudes no describe carga informática. Tampoco sabemos si el contrato de septiembre incluye exclusivamente TAMS, RSP y ASP.

La nueva resolución podría corresponder a trabajo previsto, otra fase, otro alcance o una transición ya controlada. No demuestra que ICANN haya abandonado la expectativa de mayo. Precisamente porque el expediente deja abiertas varias explicaciones, el resultado público debe identificar el estado sin convertir la redacción confidencial en acusación.

Fuentes

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. ICANN — Resoluciones aprobadas el 6 de septiembre de 2026
  5. ICANN — Resoluciones aprobadas el 3 de mayo de 2026
  6. ICANN — Informe de situación de la ronda 2026 previo a ICANN85
  7. ICANN — La ronda 2026 cierra con más de 1.600 solicitudes
  8. Programa de Nuevos gTLD — Recorrido del solicitante
  9. ICANN — Política de divulgación documental
  10. ICANN — Prácticas de publicación
  11. ICANN — Política de contratación y desembolsos