Skip to main content

Discusiones presupuestarias en la reunión ICANN61

Durante la reunión ICANN61, un tema importante de conversación fue el borrador del Presupuesto y Plan Operativo de la ICANN para el año fiscal 2019 (FY19). Como les he contado, el 80-85 por ciento de nuestro presupuesto ya está comprometido con ciertos proyectos que están en nuestros Estatutos, nuestros contratos, nuestras operaciones y otros costos fijos. Esto significa que aproximadamente el 15-20 por ciento del presupuesto total se puede examinar mientras buscamos formas de reducir nuestros gastos. Debemos trabajar juntos para determinar la mejor asignación de los fondos restantes, porque esta es su decisión, no la mía.

Una de las cosas que más valoré de esta reunión fue la buena predisposición de nuestra comunidad para ver las cosas de manera diferente, para tratar de pensar de manera diferente y para generar ideas inesperadas.

Por ejemplo, en Puerto Rico, hablamos con los líderes de las Organizaciones de Apoyo (SO) y los Comités Asesores (AC) que conforman el grupo de planificación de reuniones, a fin de explorar los factores fundamentales del costo y las consideraciones de alto nivel sobre cómo podríamos hacer que las reuniones de la ICANN sean más eficientes y efectivas. Nuestro siguiente paso es proporcionar un documento más detallado que describa opciones y recomendaciones para ser considerado por el grupo.

Durante la reunión, también hablamos mucho sobre las revisiones, una conversación que fue particularmente interesante. En el próximo año fiscal, tenemos nueve revisiones ejecutándose en varias etapas, incluida una Tercera Revisión de Responsabilidad y Transparencia (ATRT3), una continuación de la Revisión de Servicios de Directorio de Registración (RDS) y, esperamos, la Segunda Revisión de Seguridad, Estabilidad y Flexibilidad (SSR2). Muchas personas no están contentas con el elevado número de revisiones porque no tienen tiempo para participar, y expresaron su preocupación de que para la revisión ATRT3, las recomendaciones de Responsabilidad del Área de Trabajo 2 aún se encuentren siendo finalizadas; y para la Revisión del RDS, aún hay una cantidad significativa de trabajo restante en pos de abordar los impactos del Reglamento General de Protección de Datos de la Unión Europea (GDPR) sobre el sistema WHOIS. Retrasar cualquiera de estas revisiones ahorraría muchas horas de trabajo voluntario. Además, y de manera más amplia, abordar el momento de las revisiones y el enfoque contribuirá a debatir cómo hacer que las revisiones futuras sean más eficientes y más relevantes. La postergación de una revisión que se verá afectada por los Procesos de Desarrollo de Políticas actuales u otros factores externos podría resultar en ahorros significativos de productividad y costo. Por ejemplo, solamente el aplazar la Revisión ATRT3 ahorraría USD700.000, impactando así el presupuesto del próximo año.

También hubo discusiones sobre la implementación escalonada o el establecimiento de fases en las revisiones, cambiando la forma en que se realizan ciertas revisiones (limitación de viajes, cantidad de miembros del equipo de revisión, claridad en el alcance o priorización de recomendaciones, etc.) o considerando de manera diferente el momento en que se realizan las revisiones, por ejemplo programar el inicio de la próxima revisión en función de cuándo se completó la implementación de las recomendaciones de la revisión previa. Algunas de estas propuestas podrían requerir cambios en los Estatutos. Estas ideas no se tratan de eludir las responsabilidades detalladas en los Estatutos. Puedo hablar por la organización, pero estoy seguro de que la comunidad y la Junta Directiva de la ICANN estarían de acuerdo en que estamos comprometidos y siendo responsables por realizar las revisiones detalladas en los Estatutos, y que trabajaremos con la comunidad para hacer los ajustes necesarios sobre la base de los aportes y el acuerdo de la comunidad.

Muchas veces he escuchado, de varios miembros de la comunidad, sobre la necesidad y el beneficio de coordinar los planes de trabajo de las Organizaciones de Apoyo, los Comités Asesores, la Junta Directiva y la organización de la ICANN. El objetivo sería reducir la cantidad de vías paralelas en las que se está trabajando, lo que lleva a una reducción de la carga de trabajo y a una mayor eficiencia en el desarrollo de políticas o recomendaciones de la comunidad. Esta coordinación podría organizarse mediante el desarrollo de mecanismos para realizar una planificación conjunta durante el desarrollo del próximo plan estratégico.

Las ideas derivadas de estas conversaciones iniciales son sólo eso, iniciales. Es importante tener en cuenta que algunas de las ideas aquí son inconsistentes con los Estatutos, por lo tanto, si la implementación de estas ideas llega a acordarse, esto puede requerir de cambios en los Estatutos.

Estoy comenzando a ver qué cambios se pueden hacer en el ciclo de revisiones integradas en nuestros Estatutos. Estoy trabajando con mi equipo para determinar los mejores pasos a seguir en este sentido, incluido realizar otro período de comentarios públicos sobre cualquier cambio que pueda afectar a los Estatutos o las políticas. Espero con ansias sus comentarios sobre la propuesta. En última instancia, es su decisión si desean aceptar cualquier cambio en los Estatutos. Espero con ansias trabajar juntos sobre esto.

Fue bueno ver a tantos de ustedes en Puerto Rico y espero que hayan tenido un viaje seguro de regreso a casa. Ahora, a volver al trabajo.

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."