Resumen

  • El Customer Standing Committee está obligado a vigilar cada mes los niveles de servicio acordados para los nombres de la IANA, analizar el informe del operador y publicar un hallazgo, con lo que un objetivo incumplido pasa a ser una frase pública y no una excepción discreta.
  • Su hallazgo de enero de 2024 registró un incumplimiento con nombre —la verificación técnica en reensayo a 12,88 minutos frente a un umbral de diez minutos en el percentil 95— y aun así calificó el mes como satisfactorio, mientras que el de junio de 2026 registró los 64 umbrales entonces definidos como cumplidos. Entre cualquiera de esos hallazgos y una consecuencia hay pasos formales que se abren ante un fallo de procedimiento o de implementación, no ante la métrica por sí sola.

Una cifra y la frase que la aloja

El informe mensual de rendimiento de enero de 2024 contiene una línea incómoda. La verificación técnica en reensayo —rutina (técnica)— figura a 12,88 minutos frente a un umbral de diez minutos en el percentil 95 (informe del operador, enero de 2024). El mismo documento contabiliza 123 reensayos en el mes, con una media de 3,15 minutos, y atribuye la excepción a la espera de servidores de nombres inalcanzables, incluidos tiempos de espera y reintentos. Su relato lo dice con palabras del propio operador: una sola solicitud superó el umbral de diez minutos de la verificación técnica.

Las dos cifras conviven porque responden a preguntas distintas. Una media sobre 123 reensayos describe el reensayo ordinario; el umbral en cuestión está escrito para la cola de la distribución. Tres coma uno cinco minutos no pueden convertir un percentil 95 incumplido en un aprobado, y ninguna lectura honesta de la tabla se lo pide. El informe tampoco confunde ambas cosas: 12,88 es la estadística de tiempo de respuesta comparada con el umbral, no la media con un objetivo de diez minutos encima.

El comité que convierte una métrica en una frase

Quien hace la conversión es el Customer Standing Committee. Su carta enmendada fue aprobada por el consejo de la ICANN el 3 de mayo de 2026 y entró en vigor el 3 de julio de 2026, y le obliga a vigilar mensualmente los niveles de servicio acordados, analizar los informes que aporta el operador de las funciones de la IANA, publicar hallazgos mensuales y trabajar con el operador en planes de resolución de rendimiento (carta del CSC). La misma carta le pide buscar patrones sistémicos o persistentes en las quejas y le advierte, en la misma frase, que no interviene en disputas individuales entre el operador y un cliente.

La composición no la decide el comité: la fijan los estatutos. El artículo 17.2(a)(i) exige «Two individuals representing gTLD registry operators appointed by the Registries Stakeholder Group», junto a dos representantes de ccTLD nombrados por el ccNSO y un enlace de Public Technical Identifiers, con un asiento opcional para otros registros de TLD y enlaces sin voto del GNSO, la ALAC, el NRO/ASO, el GAC, el RSSAC y el SSAC. Las listas anuales las aprueban el ccNSO y el GNSO (estatutos de la ICANN).

El 14 de febrero de 2024 el comité publicó su hallazgo sobre enero de 2024. La frase general dice: «PTI met the service level agreement for 98.4% of defined metrics.» El incumplimiento nombrado fue la verificación técnica en reensayo —rutina (técnica)—. El comité aceptó la explicación del operador, no identificó ningún problema persistente, concluyó que no hacía falta ninguna acción adicional e informó que no hubo nuevas escalaciones (hallazgo del CSC, enero de 2024).

Hay que leer ese porcentaje con precisión. Mide la proporción de métricas definidas que alcanzaron su objetivo, no la proporción de solicitudes individuales atendidas a tiempo. Un mes en el que el 98,4 % de las métricas pasa es un mes con el libro mayor casi todo en verde, y es también un mes en el que una medición concreta de la cola no cruzó su línea. Ambas afirmaciones son ciertas y no son la misma.

Tres proposiciones, no una nota global

Es tentador reducir el expediente a un veredicto de rendimiento. Los documentos se resisten, y la resistencia es lo interesante. Un resultado de métrica es una medición. Un hallazgo cualitativo es un juicio sobre si esa medición señala un problema que merece seguimiento. Un registro de escalación es una afirmación sobre lo que hizo la institución después. Tres proposiciones, tres manos distintas, y la limpieza de una no avala a las otras dos.

El ciclo de junio de 2026 muestra la misma separación desde el otro lado. El hallazgo del comité, fechado el 22 de julio de 2026, afirma: «PTI met all 64 of the currently defined thresholds.» Calificó el rendimiento como excelente, no señaló métricas que requirieran seguimiento cercano e informó que no hubo nuevas escalaciones en el periodo (hallazgo del CSC, junio de 2026). El informe del operador de ese mes aporta la textura: verificación técnica inicial a 3,50 minutos frente a un techo de 50 minutos en el percentil 95, reensayo a 1,18 minutos frente a 10 minutos en el mismo percentil, validación y revisiones a 1,54 días frente a 5 días en el percentil 90, publicación de la zona raíz a 58,00 horas frente a 72 horas en el percentil 99, disponibilidad del sistema de gestión de la zona raíz al 100,00 % frente a un suelo del 99 % y exactitud del archivo de zona raíz al 100,00 % frente al 100 % (informe del operador, junio de 2026). Su tabla de síntesis se titula «Percentage of SLA thresholds met of those defined» y suma 64 de 64.

Ese título es el honesto y también la trampa. Sesenta y cuatro de sesenta y cuatro es una afirmación de conformidad sobre los umbrales vigentes en junio de 2026. No es una afirmación sobre los umbrales de enero de 2024, y esta revisión no obtuvo cotejadas las definiciones de métrica, los denominadores ni los valores objetivo de ambos periodos. Por eso aquí no se calcula ninguna mejora entre el mes del 98,4 % y el de 64 de 64. Quien quiera una tendencia necesita la tabla, no la nota.

La escalera y lo que de verdad la dispara

Entre un hallazgo publicado y una consecuencia para el operador hay un procedimiento escrito. Los procedimientos de acción correctiva del CSC y de PTI, versión 2.0, adoptados por el comité en enero de 2019 y por PTI en febrero de 2019, obligan al comité a pedir observaciones al presidente de PTI antes de cerrar un hallazgo sobre un problema de rendimiento, normalmente en diez días hábiles (procedimientos de acción correctiva). Después se envía un informe de acción correctiva al presidente de PTI, con copia al presidente de la Global Domains Division de la ICANN, y la reunión, la entrega del plan correctivo y la revisión del comité llevan plazos sucesivos de diez días hábiles.

Por encima existe la escalación por incumplimientos de obligaciones de procedimiento, implementación o reporte: al consejo de PTI, luego al director ejecutivo de la ICANN y luego al consejo de la ICANN. Si el asunto sigue sin resolverse tras eso, el comité puede plantearlo a los consejos del ccNSO y del GNSO, incluida la posibilidad de una revisión especial independiente. Los plazos de respuesta pueden modificarse por acuerdo y la implementación correctiva sigue hitos pactados en lugar de un reloj estatutario fijo.

La redacción es el hallazgo. Lo que desbloquea la escalera son fallos de proceso y de entrega, no el cruce de un objetivo numérico por sí solo. Un mes en el que una medición de la cola falla, el operador explica por qué y el comité acepta la explicación termina en el hallazgo, que es exactamente lo que muestra el expediente de enero de 2024, incluida su conclusión explícita de que no hacía falta ninguna acción adicional.

Por encima del procedimiento está el contrato. El contrato de funciones de nombres de la IANA del 30 de septiembre de 2016 obliga al contratista a «act in good faith to resolve issues identified by the CSC» (contrato de funciones de nombres). La sección 7.3(c) permite a la ICANN modificar o rescindir el acuerdo para implementar una revisión aprobada, una revisión especial o una recomendación del grupo de trabajo de los estatutos, sujeto a los estatutos. Estos fijan luego las condiciones de una revisión especial: fracaso de la acción correctiva prevista, examen por los consejos, consulta ampliada y aprobación por mayoría cualificada de ambos consejos, con comentario público cuando se solicite. La carta cierra el círculo al afirmar que el comité no puede iniciar por sí mismo la sustitución del operador mediante una revisión especial.

La secuencia que va de un incumplimiento medido a un cambio de operador pasa así por la aceptación o la acción correctiva, el consejo de PTI, el director ejecutivo de la ICANN, el consejo de la ICANN, la mayoría cualificada de dos consejos, una revisión especial y, por fin, la potestad contractual de modificar o rescindir. Cada uno de esos pasos es real y tiene participantes reales. Ninguno es la publicación de un hallazgo mensual.

El único cambio que se salta la fila

Los umbrales no están fijados en el contrato. La enmienda n.º 1, fechada y efectiva el 7 de mayo de 2019, sustituyó el anexo original para que la gestión de la zona raíz se ajuste a niveles de servicio publicados externamente y mantenidos mediante un procedimiento de cambio definido; distingue un proceso, una métrica, un umbral por solicitud individual, un tipo mínimo o máximo, un porcentaje de cumplimiento agregado y un periodo de medición (enmienda n.º 1).

El procedimiento que rige esos cambios fue modificado por última vez el 16 de julio de 2025 según su propio texto. Public Technical Identifiers, la ICANN o el comité pueden pedir un cambio; los niveles existentes no se alteran sin acuerdo mutuo; los cambios ordinarios requieren comentario público y aprobación de los dos consejos, ccNSO y GNSO. Los cambios que afectan únicamente a valores de umbral existentes están exentos de esos dos pasos (procedimiento de enmienda de los SLA).

Esa exención merece una frase llana. Un cambio que altera qué cuenta como aprobado es la única clase de cambio que no tiene que pasar por comentario público y por los dos consejos, mientras que un cambio de la métrica, del proceso o del periodo de medición sí debe pasar.

El mismo documento declara que los niveles de servicio se incorporan al contrato de funciones de nombres y son exigibles a través de él, que el procedimiento no prevalece sobre las obligaciones contractuales y que el comité debe iniciar una revisión completa de los niveles de servicio al menos cada cinco años, contados desde la conclusión de los resultados de la revisión anterior.

Nada de esto establece que algún umbral se haya movido para favorecer un hallazgo mensual. Aquí no se obtuvo ninguna serie de valores de umbral ni los criterios de calificación global del comité, así que esa inferencia no está disponible ni hace falta. Lo que el expediente sí establece es más estrecho y más útil: el denominador de «umbrales cumplidos» se mantiene aparte del hallazgo, y la forma menos visible de cambiar el significado de un mes limpio es editar la tabla.

Dónde se detiene esta revisión

El expediente tiene bordes, y van junto a las afirmaciones que limitan. El texto consolidado vigente del contrato de funciones de nombres no se obtuvo en esta revisión, y tampoco la tabla de niveles de servicio en vigor: la página de acuerdos de Public Technical Identifiers y su página de niveles de servicio para nombres solo devolvieron un aviso que exige JavaScript (acuerdos de PTI, página de SLA de nombres de PTI). Cada umbral citado arriba queda por tanto atado a enero de 2024 o a junio de 2026 y no se presenta como el objetivo actual.

El rastro de enmiendas también es irregular. Los estados financieros consolidados de la ICANN del ejercicio cerrado el 30 de junio de 2026, con informe de auditoría fechado el 6 de octubre de 2026, describen el contrato de funciones de nombres como enmendado el 24 de junio de 2024, vigente desde el 30 de septiembre de 2021, con un plazo de cinco años y renovación automática bajo ciertas condiciones, y renovado el 30 de septiembre de 2026 (estados financieros de la ICANN). Los estados del ejercicio anterior califican el mismo contrato como enmendado el 7 de mayo de 2019. No se obtuvo el texto de lo que cambió en junio de 2024, así que nada aquí supone que tocara alguna disposición citada. El documento del procedimiento de enmienda lleva el 24 de septiembre de 2025 en el nombre del archivo mientras su texto dice última modificación el 16 de julio de 2025.

Las cifras de rendimiento las declara el operador. No se identificó en el conjunto revisado ninguna auditoría independiente ni validación externa de los datos mensuales, y no se obtuvieron los criterios que convierten un mes en «satisfactorio» o «excelente». Tampoco se obtuvo una serie plurianual de hallazgos y planes de rendimiento, así que aquí no se afirma ningún patrón de escalación ni tendencia alguna. Quién emplea, financia o dirige la secretaría del comité tampoco queda establecido por estos documentos; el arreglo descrito arriba es un arreglo de funciones, información y aprobaciones, y como tal se describe.

Lo que cambiaría la lectura es concreto. Un hallazgo que nombre un incumplimiento y al que siga un informe de acción correctiva publicado. Un plan de resolución de rendimiento con fechas y un responsable identificado en el registro público. Un cambio de umbral acompañado de su fecha, su valor anterior y el nuevo. Cualquiera de esos elementos trasladaría el hallazgo mensual de evaluación con rastro documental a decisión documentada con consecuencia adjunta.

Mientras no aparezca uno, la descripción honesta de la supervisión de nombres de la IANA es un libro mayor llevado en público, revisado cada mes por un comité que debe publicar, y aplicado por puertas que se abren ante fallos de procedimiento y no ante una cifra.

La entrada del directorio para el sujeto está aquí: IANA.

Fuentes