Skip to main content

Expectativas sobre la Expectativa del Nivel de Servicio

Introducción

Recientemente, el personal de la ICANN (Corporación para la Asignación de Nombres y Números en Internet) ha estado trabajando para cumplir con los requisitos de la comunidad relativos al establecimiento de indicadores de medición para la "IANA (Autoridad de Números Asignados en Internet) posterior a la transición", a medida que procesa las solicitudes de gestión de la zona raíz. Para aquellos que no siguen el desarrollo de las Expectativas de Nivel de Servicio, los principios acordados para el monitoreo, presentación de informes y evaluación de estas solicitudes fueron:

  1. Mediciones atribuibles. Cuando resulte factible, el informe de los indicadores de medición individuales debe atribuir el tiempo invertido en cada parte responsable. Por ejemplo, el tiempo que el personal de la IANA demoró en el procesamiento de una solicitud de cambio se debe contabilizar por separado del tiempo que se dedicó a esperar una respuesta del cliente durante una solicitud de cambio.
  2. Tiempos totales. Sin perjuicio del principio anterior, existe valor en informar mediciones generales, con el fin de identificar las tendencias generales asociadas a los tiempos de procesamiento de principio a fin.
  3. Relevancia. Debe existir una distinción entre las mediciones recabadas para apoyar el análisis general, versus cuáles son las medidas críticas que se consideran importantes para el establecimiento de umbrales específicos, a fin de juzgar las brechas que puedan existir en la capacidad de la ICANN para proporcionar un nivel de servicio adecuado.
  4. Definición clara. Cada indicador de medición debe estar bien definido para garantizar un entendimiento común de lo que se está midiendo y cómo se implementaría un enfoque automatizado para medir en comparación con la norma.
  5. Definición de umbrales. La definición de los umbrales específicos para los criterios de desempeño debe basarse en el análisis de datos reales. Esto puede primero requerir la definición de un indicador de medición, un período de recolección de datos y, luego, el análisis por parte de la comunidad, antes de poder definir el umbral.
  6. Proceso de revisión. Las expectativas de nivel de servicio deben revisarse periódicamente y adaptarse según las expectativas revisadas de la comunidad y de las actualizaciones pertinentes al ambiente. Deben tener el acuerdo mutuo de la comunidad y del Operador de las Funciones de la IANA.
  7. Informes periódicos. Siempre que sea factible, el informe de las mediciones debe ser regular y debe intentar ajustarse al tiempo real.

A partir del 2 de marzo, se han estado produciendo los cambios de código necesarios para permitir la recolección de información de tiempos para las Expectativas de Nivel de Servicio. El siguiente paso puede ser considerar lo que haremos con los datos recabados. En esta publicación presentaremos cómo hemos llegado a donde nos encontramos ahora, y qué esperar en el futuro.

Antecedentes: Establecimiento de los requisitos de medición

Se encargó a un Equipo de Diseño de un Grupo de Trabajo Intercomunitario (CWG), específicamente ("DT-A"), desarrollar normas de desempeño. El DT-A ha desarrollado un conjunto de indicadores de medición para recolectar datos con el fin de evaluar los niveles de servicio ofrecidos por la función de gestión de la zona raíz de la IANA. Este proceso de desarrollo incluyó tanto a personal de la ICANN como a expertos en la materia, quienes examinaron todo el proceso de gestión de la zona raíz en forma detallada, conjuntamente con el Equipo de Diseño, explicando cómo funciona y deliberando sobre las implicaciones de las diversas mediciones propuestas. El personal de la ICANN contribuyó con explicaciones de los flujos de procesamiento típicos, así como mediante el intercambio de casos inusuales que pueden complicar algunas mediciones, más allá de lo percibido a primera vista. Mientras que el personal de la ICANN no estableció los indicadores de medición, asesoramos al Equipo de Diseño cuando consideramos que ciertas mediciones serían imposibles de recabar. La conclusión de este trabajo es el informe final del Equipo de Diseño, que formó parte de la propuesta del CWG.

Implementación: Adición de nuevas capacidades de medición al RZMS

Desde la finalización de la propuesta del CWG, el equipo que desarrolla el Sistema de Gestión de la Zona Raíz de la ICANN (RZMS) ha trabajado para instrumentar el sistema para capturar los eventos del sistema relacionados a los nuevos indicadores de medición propuestos. Esto era necesario ya que algunas de las mediciones del trabajo del Equipo de Diseño se refieren a detalles finos de ciertos flujos de procesos que no fueron originalmente registrados. Tal como se ha mencionado, este trabajo se ha completado y la primera versión, que es compatible con este nuevo registro, fue desplegada el 2 de marzo de 2016. El personal de la ICANN analizará los primeros lotes de datos de registro a fin de determinar la necesidad o no de un mayor refinamiento para calcular e informar exitosamente en virtud de la SLE (Expectativa del Nivel de Servicio).

Producción

Recolección de datos iniciales

Con las nuevas capacidades de recopilación de las estadísticas de desempeño del RZMS en vigencia, el personal de la ICANN ha comenzado la recolección de datos sin procesar. Estos datos constituirán la base de las futuras conversaciones con la comunidad de gestión de la zona raíz más amplia, es decir, con las muchas organizaciones que gestionan los TLD (Dominios de Alto Nivel). En estas conversaciones, esperamos explorar cuáles indicadores de medición son fundamentales y cuál debería ser el rendimiento de la IANA posterior a la transición en relación a dichas mediciones. La propuesta del CWG requiere el establecimiento de niveles de servicio mediante el análisis de datos reales, y estos datos serán utilizados en ese análisis. Dadas las limitaciones de tiempo asociadas con la transición y nuestras expectativas de que los indicadores de medición deben evolucionar con el tiempo, creemos que una recolección de datos inicial de tres (3) meses será suficiente como para establecer una línea de base para los umbrales iniciales, como veremos a continuación.

Integración de datos y presentación de informes

Mientras que la recolección inicial de datos está en marcha, el personal de la ICANN desarrollará los sistemas y las herramientas necesarias para integrar el flujo de datos sin procesar y convertirlos a los formatos que la comunidad espera. Estos formatos incluirán una vista de panel adecuado para su publicación en tiempo real, así como informes periódicos que necesitan ser generados. Además, se publicará una versión de los registros sin procesar ―resguardando la información confidencial―, para permitir a terceros que realicen su propio análisis y mediciones, así como para ofrecer una forma de verificar nuestra interpretación de los datos de manera independiente. Compartiremos nuestro progreso a medida que la recopilación de datos y las herramientas sean desarrolladas, y publicaremos los datos tan pronto como tengamos confianza respecto a su exactitud.

Establecimiento de umbrales y niveles de servicio

Con suficientes datos en la mano como para llevar a cabo un análisis exhaustivo, y con las herramientas necesarias para analizar e informar los datos desplegados, trabajaremos con la comunidad de los administradores de TLD para identificar cuáles son los "indicadores de medición críticos", y cuáles deberían ser sus umbrales.  Estos umbrales, una vez acordados entre el personal de la ICANN y la comunidad, serán los nuevos estándares de desempeño para la gestión de la zona raíz en el entorno posterior a la transición. Más allá de esto, los mecanismos de retroalimentación habituales que se definen en la propuesta de transición, incluso el Comité Permanente de Clientes (CSC) recién conformado, brindarán información para la futura evolución de la presentación de informes y del desempeño esperado a partir de la gestión de la zona raíz de la IANA.

Conclusión

Hemos empezado a recabar las mediciones que la comunidad y el personal de la ICANN han acordado. A medida que se obtengan los datos relativos a los tiempos de las acciones de gestión de la zona raíz por parte del personal, la comunidad y otras partes, el personal de la ICANN espera con interés trabajar con la comunidad para cotejarlos y colocarlos a disposición de aquellos interesados en mantener el compromiso de apertura y transparencia de la ICANN. Anticipamos que un período de tres (3) meses de recolección de mediciones brindará datos suficientes como para establecer objetivos de desempeño para la IANA. Una vez que se haya implementado la transición, el CSC podrá evaluar el desempeño de la gestión de la zona raíz de la IANA y ajustar los niveles de servicio específicos para satisfacer mejor las necesidades de la comunidad.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."